摘要：
讨论关于建立ASP.NET Web页的事件模型和转化为HTML的各个过程的细节。ASP.NET HTTP 运行时管理着把请求URL转换成一个页面类的具体实例的对象管道，接下来把这些实例转换成一般的HTML文本格式。本文对代表各个页面生命周期的事件、怎么控制页面执行、开发人员怎么干预这些标准行为的执行过程进行了讲解。
介绍
每当请求IIS容纳的ASP.NET页时，总是要把请求转交给了ASP.NET HTTP 管道。HTTP管道是一组被控对象，这些对象按顺序处理请求并且把这些请求转换成一般HTML文本。HTTP管道的入口是HttpRuntime 类。ASP.NET的底层结构为每一个应用程序域 （ AppDomain ）的工作进程建立了一个这个类（HttpRuntime）的实例（注意，一个工作进程只能支持一个正在运行的ASP.NET应用域）。
HttpRuntime 类从内部程序池中选择一个 HttpApplcation 对象，并且在接收到请求的时候使它工作。Http应用管理程序的主要工作是寻找这样的类使之能够处理请求。例如：当请求一个.aspx资源时，处理句柄就是一个从Page继承类的实例。请求资源的类型和相关处理句柄的关系映射表被保存在应用程序的配置文件里。更确切的说，这个映射表就定义在machie.config里的<httpHandlers>一节里。但是，应用程序能在web.config里对这个HTTP处理句柄映射列表进行重定义。下面这行语句说明了定义.aspx资源请求的处理句柄：
<add verb=”*” path=”*.aspx” type=”System.Web.UI.PageHandlerFactroy”/>
一个扩展可以和一个句柄类联系起来，更一般说，是和一个句柄工厂类相联系。在所有情况下，负责处理请求的HttpApplication对象得到一个从IHttpHandler接口具体实现的对象。如果是根据HTTP句柄来处理资源和相关处理类的关系，则返回类是直接实现相关的接口的；如果资源是绑定到一个句柄工厂的话，将必须经过另外一个阶段：具体实现IHttpHandlerFactory接口的句柄工厂类的GetHandler方法将返回一个基于IHttpHandler的对象。
Http运行时怎么结束一个周期或关闭一个页面请求的进程呢？IHttpHandler接口的ProcessRequest方法拥有这个功能。调用代表被请求页面的对象的该方法，ASP.NET底层结构打开一个进程来为浏览器产生输出。
Page类
一个页面的HTTP处理句柄的类型取决于URL。当这个URL被首次访问，一个新的类将被构建并动态的编译成一个程序集。一个分析aspx文件的进程从aspx文件中分离出这个类的代码。在默认情况下，这个类被加入到一个叫做asp的名字空间里，并且把URL作为这个类的类名。例如，如果请求的URL是page.aspx，则这个类就是ASP.Page_aspx。这个类名，可以通过设置@Page预处理指令的ClassName属性来修改。
HTTP句柄的基础类是Page类。这个类定义了一组最小方法和属性集，这些方法和属性被所有的页面处理句柄所共享。Page类具体实现了IHttpHandler接口。
在另外一种和上述相对应的情况中，实际处理页面的句柄的基础类并不是Page类，而是一个别的类。当使用后代码模式时，这个情况就发生了。后代码是一种将C#或VB.NET代码和页面分离的技术。页面代码是一组事件处理句柄和其他一些方法的集合，这些方法定义了页面的各种行为。这些代码可以以内联形式用<script runat=server>标签定义，或者你可以用外部类形式来写——这就是后代码模式。后代码类是从Page类继承的，但是具体化或者重新定义了一些其他的方法。在指定了页面的后代码类后，这个后代码类就作为HTTP处理句柄。
在其他的情况下，如果应用程序的配置文件中重定义了<pages>节的PageBaseType属性，则HTTP处理句柄不是基于Page类的，例如：
<pages PageBaseType = “Classes.MyOage , mypage” />
PageBaseType属性指明了包含页面处理句柄父类的类型和程序集。来自Page类的这些类自动赋予一些通常或扩展的方法和属性的集合给处理句柄。
页面生命周期
一旦HTTP页面处理句柄被明确的定义了，ASP.NET运行时调用处理句柄的ProcessRequest方法来处理请求。通常，没有必要改变Page类提供的执行方法。
页面执行是从FrameworkInitialize方法开始的，这个方法为页面构建控件树。该方法是TemplageControl类的受保护并且是虚方法。任何为aspx资源动态生成的句柄覆盖了该方法。在这个方法里，页面的所有控件树都被构建了。
接下来，ProcessRequest方法使页面经历了不同的几个阶段：初始化、加载视图状态信息、回传数据、加载页面代码和执行回传的服务器事件。在这之后，页面转换到了显示模式：收集被更新的视图状态；产生HTML代码，并且传送到控制台。最后，页面卸载，请求的全部服务结束了。
在各个不同阶段里，页面处理了与web控件相关、程序员代码能够干预并解决一定问题的事件。其间一些事件是专门为那些内嵌控件和不能在.aspx代码级别处理的控件而设计的。
一个页面要解决这样的事件，它能明确的注册成为合适的句柄。但是，为了和原有的Visual Basic编程模式有后向兼容性，ASP.NET也支持了隐含事件的形式。在默认情况下，页面会寻找和事件相关的方法名；如果找到和事件相匹配的方法，这个方法就被认为是这种事件的处理程序。ASP.NET提供了六种专门的方法名，他们是 Page_Init , Page_Load , Page_DataBind , Page_PreRender 和 Page_Unload 。这些方法这些方法在Page类中已经被定义过，他们是相应事件的处理程序。HTTP运行时将自动的将这些方法绑定到相关的页面事件，而不需要程序员去编写把事件和方法联系起来的代码。举个例子来说，在下面的代码中， Page_Load方法和页面的加载事件相关联：
this.Load + = new EventHandler(this.Page_Load);
这种自动识别是被 @Page 预指令的AutoEventWireup 属性控制的。如果这个属性被置false ，应用程序必须显式声明和事件相关的方法。不自动关联页面事件代码的页面执行起来会快一些，是因为他们不需要在匹配上做过多的工作。在Visual Studio.NET 工程里可以把这个属性关闭掉。但是，默认设置是true，这意味着Page_Load方法被自动识别并被关联到相关的事件。
页面执行包含了下表中按顺序列出的几个阶段，他们被标志成为应用程序级别的事件，同时也可能是一些受保护、重定义的方法：
|
阶段 |
页面事件 |
可重定义的方法 |
|
页面初始化 |
Init |
|
|
视图状态加载 |
|
LoadViewState |
|
回传数据处理 |
|
控件里实现了IPostBackDataHandler接口的LoadPostData方法 |
|
页面加载 |
Load |
|
|
回传数据变化检查 |
|
控件里实现了IPostBackDataHandler接口的RaisePostDataChangedEvent方法 |
|
回传事件处理 |
控件里定义的回传事件 |
控件里实现了IPostBackEventHandler接口的RaisePostBackEvent方法 |
|
页面预返回阶段 |
PreRender |
|
|
页面返回阶段 |
|
Render |
|
页面卸载阶段 |
Unload |
|
上表中列出的阶段有的在页面级别是不可见的，他们只是在服务器控件的作者编写继承于Page的类时会使用到。Init , Load , PreRender , Unload，再加上定义在内嵌控件中的回传处理事件，他们构成了页面的整个生命周期。