在 Web 部件应用程序中使用 ASP.NET 服务器控件
更新：2007 年 11 月
在 Web 部件应用程序中，主用户界面 (UI) 由驻留在区域（即网页上具有公共 UI 并由从 WebPartZoneBase 类派生的一种复合控件创建的区域）内的 ASP.NET 服务器控件组成。对于组成 Web 部件应用程序的主 UI 的这些服务器控件，其功能是在 WebPart 基类中定义的，但并不限制您使用从该类派生的控件。您也可以使用任何标准的 ASP.NET 服务器控件、用户控件或自定义服务器控件。本主题讨论当 Web 部件应用程序中的服务器控件并不是从 WebPart 类继承时使用这些控件的一些问题。
创建运行时 Web 部件控件
对于不是从 WebPart 类继承的各种服务器控件，Web 部件控件集提供了一种机制，可以使这些控件参与 Web 部件应用程序并具有与从 WebPart 类派生的控件相同的功能。此机制不需要开发人员执行任何特殊操作；所有必须做的事情只是将服务器控件添加到 WebPartZoneBase 区域。在编译网页时，会自动使用 GenericWebPart 类的一个实例包装位于某个区域中且不是从 WebPart 类继承的任何服务器控件，这样的控件将变成该实例的子控件。由于 GenericWebPart 类是从 WebPart 类继承，因此该服务器控件现在将具有 WebPart 控件的全部功能。实际上，开发人员通过将不是从 WebPart 类继承的服务器控件添加到 WebPartZoneBase 区域，即可使控件变成运行时 WebPart 控件。
.gif "说明") 说明： |
|---|
如同可以在 Web 部件应用程序中使用服务器控件，您也可以在 Web 部件应用程序的外面使用 WebPart 控件。如果将不是从 WebPart 类继承的某个控件添加到区域之外的页面，则该控件将用作普通服务器控件，并只丢失其 Web 部件功能。 |
将 ASP.NET 服务器控件添加到区域
在将 ASP.NET 服务器控件、用户控件或自定义控件添加到 WebPartZoneBase 区域时，不需要在页面上使用任何特殊的技术或声明。在将这些控件添加到区域时，可以使用通常将控件添加到网页的方式：以声明方式（使用页面持久性格式）或编程方式。另外，还可以使用 Web 部件目录功能。使用该功能可以将服务器控件添加到目录中，而用户可以在运行时从该目录中选择控件并将其添加到页面。有关更多信息，请参见 DeclarativeCatalogPart 和 ImportCatalogPart 控件。
如果以编程方式将服务器控件添加到区域，则建议使用 WebPartManager 控件的 AddWebPart 方法进行添加。
当以声明方式将非 WebPart 控件的服务器控件添加到区域时，如果使用 Microsoft Visual Studio 2005 等可视化设计工具，则在属性窗格或 IntelliSense 中看不到 WebPart 属性和成员。有关更多信息，请参见下一节。下一节将讨论何时使用 WebPart 控件以及其他服务器控件。
决定何时使用不同的服务器控件选项
由于您可以在 Web 部件应用程序中使用任何类型的服务器控件，因此可能不清楚是否有必要创建从 WebPart 类派生的控件。
需要考虑的关键因素是，改编预先存在的服务器控件与通过从 WebPart 类派生来创建新的服务器控件各自具有的优点。下面的原则可能会帮助您做出决策。
使用服务器控件
在许多情况下，创建 Web 部件控件的首选选项是使用 ASP.NET 服务器控件、用户控件或自定义控件，尤其在这些控件已经存在时更是如此。如果使用这几种服务器控件，不仅不会丢失任何运行时 Web 部件功能，还能得到许多好处，例如重用现有代码的能力以及利用您的控件开发知识并将其应用于 Web 部件应用程序的能力。
此外，通过实现 WebPart 类所实现的几个接口，还可以使各个服务器控件与真正的 WebPart 控件具有相同的行为。包括：
IWebActionable 接口。如果实现此接口，则能够将自定义谓词（即 UI 中用户可以对控件执行的常见操作，如最小化、关闭或编辑）添加到控件的谓词菜单。
IWebEditable 接口。如果实现此接口，则能够将自定义 EditorPart 控件与服务器控件相关联，从而使用户可以编辑指定的自定义属性和控件在运行时的行为。
IWebPart 接口。如果实现此接口，则您的控件将具有从 Part 类继承的真正的 WebPart 控件的许多属性。这样，即使在设计时，它也与 WebPart 控件具有相同的外观。
从 Web 部件派生
通过从 WebPart 类派生来创建控件的主要好处是可以完全控制其特定于 Web 部件的行为。
此好处一个示例是：控件开发人员希望更改控件的运行时行为，然后将它重新发布给用户。开发人员可以重写 WebPart 类的其中一个虚拟属性（如 AllowClose），并使它成为总是返回 false 的只读属性。这样可禁止关闭控件，而该控件的用户将受到此行为的限制。
通过继承 WebPart 类能够得到好处的另一个示例与设计时行为有关。对于 WebPart 控件，页面开发人员在设计时可以通过 IntelliSense 看到所有公开的 WebPart 成员（如果开发人员使用 Microsoft Visual Studio 2005 等可视化设计工具），从而可以在声明模式中和**“属性”窗格中使用属性。相反，如果在设计时在区域中声明服务器控件，并且这些控件不是 WebPart 控件，则在 IntelliSense 中或“属性”**窗格中看不到特定于 WebPart 类的任何成员（但您仍可以声明它们）。这是因为在设计时，尚未使用 GenericWebPart 对象封装普通服务器控件，因此它不具有在运行时具有的 WebPart 功能。虽然实现上面列出的接口可以使服务器控件的外观和行为类似于 WebPart 控件，但通常仅创建 WebPart 控件将更加直接。创建控件包的控件开发人员和供应商得益于从 WebPart 类派生，他们可以通过派生为控件提供更丰富的设计时功能。
结束语
综上，如果不需要重写控件的标准属性，您可能会发现使用预先存在的服务器控件并将其设置为 WebPart 控件的一部分将更为简单。
如果您决定创建一个自定义 WebPart 控件，则可能会重写下列属性：
用户控件与 Web 部件控件相同
对于 ASP.NET 开发人员来说，用户控件是一中功能强大的选项，因为借助它们，开发人员可以使用网页中所用的相同声明性语法来迅速生成控件的复杂 UI。此外，用户控件还为跨多页进行分区和重用代码提供了一种简便的方法。用户控件与 ASP.NET 服务器控件相同，也是供在 Web 部件应用程序中使用的极好的选择。可以直接将用户控件添加到 WebPartZoneBase 区域，而其功能与运行时 WebPart 控件相同，如上面所述。用户控件也可以与 Web 部件目录功能一起使用，此时可以用作可导入的控件，或者将用户可选择和添加到页面中的一组其他服务器控件进行打包（有关更多信息，请参见 WebPartsListUserControlPath 属性）。
.gif "重要说明") 重要说明： |
|---|
您应清楚对于用作运行时 WebPart 控件的用户控件，将禁用 ASP.NET 输出缓存。Web 部件控件集要求控件应位于对页面的每个请求的控件树中。为使某些 Web 部件功能（例如个性化设置，有关更多信息，请参见 Web 部件个性化设置概述）正确运行，必须满足此要求。当请求对用户控件进行缓存时（有关更多信息，请参见 @ OutputCache 指令），不会将该控件添加到控件树中。因此，输出缓存与 Web 部件功能不兼容，并且，与 Web 部件应用程序中的 WebPart 控件功能相同的用户控件不与输出缓存一起使用。 |