ASP.NET Page那点事(1)

Page，我想每个ASP.NET开发人员对它应该都是比较熟悉的。

这次的博客我就打算专门谈谈它。不过呢，我不打算说 在Page中使用控件的一些话题，也不会说Page的生命周期的相关话题，因为我认为这些话题被人谈论的次数实在是太多了，尤其是市面上的ASP.NET的书籍，都会比较喜欢这些话题。

我不喜欢重复，因此今天我只想谈些人家不谈的那点事，但我认为它们仍然很重要。

一些重要的Page指令

虽然Page公开了很多属性，让我们可以在运行时调整它的状态与行为，但是，还有些重要的参数却是以“指令”方式提供的，需要在设计时就指定。

下面是我整理的一些我认为 比较重要并且经常需要使用的指令：

 

web.config的全局设置

前面我介绍了一些常用的Page指令，考虑到方便性，ASP.NET还允许我们在web.config中为一些常用的指令配置默认值。下面我就一些常用的场景来说明这些全局配置的方便性。

1. 通常，我在创建一个网站项目时，肯定会决定不使用ViewState和Session的。那么如果为每个页面设置EnableViewState，EnableSessionState指令属性，那就显得太麻烦了，而且还容易遗漏。此时，我们可以直接在web.config中为这些参数指定一个全局的默认值：

<pages enableViewState="false" enableSessionState="false"></pages>

补充说明一下：全局禁用Session的彻底方法是把Session对应的HttpModule从httpModules列表中移除。

web.config允许我们设置Page默认参数的具体配置节如下：

<pages
   buffer="[True|False]"
   enableEventValidation="[True|False]"
   enableSessionState="[True|False|ReadOnly]"
   enableViewState="[True|False]"
   enableViewStateMac="[True|False]"
   smartNavigation="[True|False]"
   autoEventWireup="[True|False]"
   pageBaseType="typename, assembly"
   userControlBaseType="typename"
   validateRequest="[True|False]"
   masterPageFile="file path"
   theme="string"
   styleSheetTheme="string"
   maxPageStateFieldLength="number"
   compilationMode="[Always|Auto|Never]"
   pageParserFilterType="string"
   viewStateEncryptionMode="[Always|Auto|Never]"
   maintainScrollPositionOnPostBack="[True|False]"
   asyncTimeout="number"
>
   <controls>...</controls>
   <namespaces>...</namespaces>
   <tagMapping>...</tagMapping>
</pages>

2. 为了代码重用，设计用户控件也是很常用的方法。

我们可以使用 @ Register指令 在页面注册需要使用的UserControl或者WebControl。然而，有些控件比较通用，许多页面都会使用它，那么就不要再使用 @ Register指令了，可以在web.config中统一注册。例如：

<pages>
    <controls>
        <add tagPrefix="fish" tagName="MainMenu" src="~/Controls/MainMenu.ascx" />
        <add tagPrefix="fish" tagName="PageHeader" src="~/Controls/PageHeader.ascx" />
    </controls>
</pages>

有了这个定义后，我就可以在任何页面中直接使用：

<fish:PageHeader runat="server" ID="PageHeader1" />

3. 对于喜欢使用页面内联代码的人来说，可能经常需要使用自己定义的类型。如果这些类型定义在某个命名空间中，那么就需要在内联代码中采用完整命名空间的写法。虽然这样做没有什么问题，但就是麻烦，于是，我们可以在页面中使用 @ Import指令 来导入我们需要使用的命名空间，但是这个指令每次只能导入一个命名空间，而且每个页面还得重复导入，显然不够方便。

为了方便使用一些常用的命名空间，我们可以在web.config中统一指定，例如：

<pages>
    <namespaces>
        <add namespace="MyMVC" />
        <add namespace="WebSiteCommonLib" />
        <add namespace="WebSiteModel" />
    </namespaces>
</pages>

这样设置后，所有页面就可以直接使用这些命名空间下的类型了。

不知道有些人想过：为什么在页面中使用某些微软提供的类型就不需要导入命名空间？

答案是：其实ASP.NET已经将一些微软认为常用的命名空间在web.config中配置好了：

<pages>
    <namespaces>
        <add namespace="System"/>
        <add namespace="System.Collections"/>
        <add namespace="System.Collections.Specialized"/>
        <add namespace="System.Configuration"/>
        <add namespace="System.Text"/>
        <add namespace="System.Text.RegularExpressions"/>
        <add namespace="System.Web"/>
        <add namespace="System.Web.Caching"/>
        <add namespace="System.Web.SessionState"/>
        <add namespace="System.Web.Security"/>
        <add namespace="System.Web.Profile"/>
        <add namespace="System.Web.UI"/>
        <add namespace="System.Web.UI.WebControls"/>
        <add namespace="System.Web.UI.WebControls.WebParts"/>
        <add namespace="System.Web.UI.HtmlControls"/>
    </namespaces>
</pages>

4. 现在，有越来越多的人为了方便而使用扩展方法。使用扩展方法的好处是：可以让我们不去关心这些扩展方法定义在那个类中，只要在支持扩展方法的对象上调用就可以了，就像下面的代码这样：

当前用户已登录，登录名：<%= Context.User.Identity.Name.HtmlEncode() %>

然而，在页面中使用扩展方法时，也必须先导入扩展方法的定义类的命名空间。

因此，为了方便，我们可以在web.config中为我们定义的扩展方法导入相应的命名空间：

<pages>
    <namespaces>
        <add namespace="FishDemoCodeLib" />
    </namespaces>
</pages>