LoadControl 和输出缓存

极少有不使用用户控件的 ASP.NET 应用程序。在出现母版页之前，开发人员使用用户控件来提取公用内容，如页眉和页脚。即使在 ASP.NET 2.0 中，用户控件也提供了有效的方法来封装内容和行为以及将页面分为多个区域，这些区域的缓存能力可以独立于作为整体的页面进行控制（一种称为段缓存的特殊输出缓存形式）。

用户控件可以采用声明的方式加载，也可以强制加载。强制加载依赖于 Page.LoadControl，它实例化用户控件并返回控件引用。如果用户控件包含自定义类型的成员（例如，公共属性），则您可以转换该引用并从您的代码访问自定义成员。图 1 中的用户控件实现名为 BackColor 的属性。以下代码加载用户控件并向 BackColor 分配一个值：

protected void Page_Load(object sender, EventArgs e)
{
// 加载用户控件并将其添加到页面中
Control control = LoadControl("~/MyUserControl.ascx");
PlaceHolder1.Controls.Add(control);

// 设置其背景色
((MyUserControl)control).BackColor = Color.Yellow;
}

以上代码实际上很简单，但却是一个等待粗心的开发人员掉进去的陷阱。您能找出其中的破绽吗？

如果您猜到该问题与输出缓存有关，那么您是正确的。正如您所看到的一样，上述代码示例编译和运行都正常，但是如果尝试将以下语句（完全合法）添加到 MyUserControl.ascx 中：

<%@ OutputCache Duration="5" VaryByParam="None" %>

则当您下一次运行该页面时，您将看到 InvalidCastException (oh joy!) 和以下错误消息：

“无法将类型为‘System.Web.UI.PartialCachingControl’的对象转换为类型‘MyUserControl’。”

因此，此代码在没有 OutputCache 指令时运行正常，但如果添加了 OutputCache 指令就会出错。ASP.NET 不应该以这种方式运行。页面（和控件）对于输出缓存应该是不可知的。那么，这代表什么意思？

问题在于为用户控件启用输出缓存时，LoadControl 不再返回对控件实例的引用；相反，它返回对 PartialCachingControl 实例的引用，而 PartialCachingControl 可能会也可能不会包装控件实例，具体取决于控件的输出是否被缓存。因此，如果开发人员调用 LoadControl 以动态加载用户控件并且为了访问控件特定的方法和属性而转换控件引用，他们必须注意进行该操作的方式，以便不管是否具有 OutputCache 指令，代码都可以运行。

图 2 说明动态加载用户控件以及转换返回的控件引用的正确方法。以下是其工作原理概要：

不管 .ascx 文件中是否具有 OutputCache 指令，图 2中的代码都将运行。虽然看起来复杂一点，但它会避免烦人的错误。简单并不总是代表易于维护。

视图状态：无声的性能杀手

从某种意义上说，视图状态是有史以来最伟大的事情。毕竟，视图状态使得页面和控件能够在回发之间保持状态。因此，您不必像在传统的 ASP 中那样编写代码，以防止在单击按钮时文本框中的文本消失，或在回发后重新查询数据库和重新绑定 DataGrid。

但是视图状态也有缺点：当它增长得过大时，它便成为一个无声的性能杀手。某些控件（例如文本框）会根据视图状态作出相应判断。其他控件（特别是 DataGrid 和 GridView）则根据显示的信息量确定视图状态。如果 GridView 显示 200 或 300 行数据，我会望而生畏。即使 ASP.NET 2.0 视图状态大致是 ASP.NET 1 x 视图状态的一半大小，一个糟糕的 GridView 也可以容易地将浏览器和 Web 服务器之间的连接的有效带宽减少 50％ 或更多。

您可以通过将 EnableViewState 设置为 false 来关闭单个控件的视图状态，但某些控件（特别是 DataGrid）在不能使用视图状态时会失去某些功能。控制视图状态的更佳解决方案是将其保留在服务器上。在 ASP.NET 1.x 中，您可以重写页面的 LoadPageStateFromPersistenceMedium 和 SavePageStateToPersistenceMedium 方法并按您喜欢的方式处理视图状态。图 4 中的代码显示的重写可防止视图状态保留在隐藏字段中，而将其保留在会话状态中。当与默认会话状态进程模型一起使用时（即，会话状态存储在内存中的 ASP.NET 辅助进程中时），在会话状态中存储视图状态尤其有效。相反，如果会话状态存储在数据库中，则只有测试才能显示在会话状态中保留视图状态会提高还是降低性能。

在 ASP.NET 2.0 中使用相同的方法，但是 ASP.NET 2.0 能够提供更简单的方法将视图状态保留在会话状态中。首先，定义一个自定义页适配器，其 GetStatePersister 方法返回 .NET Framework SessionPageStatePersister 类的一个实例：

public class SessionPageStateAdapter :
System.Web.UI.Adapters.PageAdapter
{
public override PageStatePersister GetStatePersister ()
    {
return new SessionPageStatePersister(this.Page);
    }
}

然后，通过将 App.browsers 文件按以下方式放入应用程序的 App_Browsers 文件夹，将自定义页适配器注册为默认页适配器：

<browsers>
<browser refID="Default">
<controlAdapters>
<adapter controlType="System.Web.UI.Page"
adapterType="SessionPageStateAdapter" />
</controlAdapters>
</browser>
</browsers>

（您可以将文件命名为您喜欢的任何名称，只要它的扩展名为 .browsers 即可。）此后，ASP.NET 将加载页适配器并使用返回的 SessionPageStatePersister 以保留所有页面状态，包括视图状态。

使用自定义页适配器的一个缺点是它全局性地作用于应用程序中的每一页。如果您更愿意将其中一些页面的视图状态保留在会话状态中而不保留其他页面的视图状态，请使用图 4 中显示的方法。另外，如果用户在同一会话中创建多个浏览器窗口，您使用该方法可能会遇到问题。

未缓存的角色

以下语句经常出现于 ASP.NET 2.0 应用程序的 web.config 文件以及介绍 ASP.NET 2.0 角色管理器的示例中：

<roleManager enabled="true" />

但正如以上所示，该语句确实会对性能产生明显的负面影响。您知道为什么吗？

默认情况下，ASP.NET 2.0 角色管理器不会缓存角色数据。相反，它会在每次需要确定用户属于哪个角色（如果有）时参考角色数据存储。这意味着一旦用户经过了身份验证，任何利用角色数据的页（例如，使用启用了安全裁减设置的网站图的页，以及使用 web.config 中基于角色的 URL 指令进行访问受到限制的页）将导致角色管理器查询角色数据存储。如果角色存储在数据库中，那么对于每个请求需要访问多个数据库的情况，您可以轻松地免除访问多个数据库。解决方案是配置角色管理器以在 Cookie 中缓存角色数据：

<roleManager enabled="true" cacheRolesInCookie="true" />

您可以使用其他<roleManager> 属性控制角色 Cookie 的特征 — 例如，Cookie 应保持有效的期限（以及角色管理器因此返回角色数据库的频率）。角色 Cookie 默认情况下是经过签名和加密的，因此安全风险虽然不为零，但也有所缓解。