了解ASP.NET页面对象模型(1)

     摘要：了解为 ASP.net Web 页面建立的事件模型，以及 Web 页面转变为 HTML 过程中的各个阶段。ASP.NET HTTP 运行时负责管理对象管道，这些对象首先将请求的 URL 转换成 Page 类的具体实例，然后再将这些实例转换成纯 HTML 文本。本文将探讨那些作为页面生命周期标志的事件，以及控件和页面编写者如何干预并改变标准行为。
  　　简介
  
  　　对由 Microsoft? Internet 信息服务 (IIS) 处理的 Microsoft? ASP.NET 页面的每个请求都会被移交到 ASP.NET HTTP 管道。HTTP 管道由一系列托管对象组成，这些托管对象按顺序处理请求，并将 URL 转换为纯 HTML 文本。HTTP 管道的入口是 HttpRuntime 类。ASP.NET 结构为辅助进程中的每个 AppDomain 创建一个此类的实例。（请注意，辅助进程为每个当前正在运行的 ASP.NET 应用程序维护一个特定的 AppDomain。）
  
  　　HttpRuntime 类从内部池中获取 HttpApplication 对象，并安排此对象来处理请求。HTTP 应用程序管理器完成的主要任务就是找到将真正处理请求的类。当请求 .aspx 资源时，处理程序就是页面处理程序，即从 Page 继承的类的实例。资源类型和处理程序类型之间的关联关系存储在应用程序的配置文件中。更确切地说，默认的映射集是在 machine.config 文件的 ＜httpHandlers＞ 部分定义的。但是，应用程序可以在本地的 web.config 文件中自定义自己的 HTTP 处理程序列表。以下这一行代码就是用来为 .aspx 资源定义 HTTP 处理程序的。
  
  ＜add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/＞
  
  　　扩展名可以与处理程序类相关联，并且更多是与处理程序工厂类相关联。在所有情况下，负责处理请求的 HttpApplication 对象都会获得一个实现 IHttpHandler 接口的对象。如果根据 HTTP 处理程序来解析关联的资源/类，则返回的类将直接实现接口。如果资源被绑定到处理程序工厂，则还需要额外的步骤。处理程序工厂类实现 IHttpHandlerFactory 接口，此接口的 GetHandler 方法将返回一个基于 IHttpHandler 的对象。
  
  　　HTTP 运行时是如何结束这个循环并处理页面请求的？ProcessRequest 方法在 IHttpHandler 接口中非常重要。通过对代表被请求页面的对象调用此方法，ASP.NET 结构会启动将生成浏览器输出的进程。
  
  　　真正的 Page 类
  
  　　特定页面的 HTTP 处理程序类型取决于 URL。首次调用 URL 时，将构建一个新的类，这个类被动态编译为一个程序集。检查 .aspx 资源的分析进程的结果是类的源代码。该类被定义为命名空间 ASP 的组成部分，并且被赋予了一个模拟原始 URL 的名称。例如，如果 URL 的终点是 page.aspx，则类的名称就是 ASP.Page_aspx。不过，类的名称可以通过编程方式来控制，方法是在 @Page 指令中设置 ClassName 属性。
  
  　　HTTP 处理程序的基类是 Page。这个类定义了由所有页面处理程序共享的方法和属性的最小集合。Page 类实现 IHttpHandler 接口。
  
  　　在很多情况下，实际处理程序的基类并不是 Page，而是其他的类。例如，如果使用了代码分离，就会出现这种情况。代码分离是一项开发技术，它可以将页面所需的代码隔离到单独的 C# 和 Microsoft Visual Basic? .NET 类中。页面的代码是一组事件处理程序和辅助方法，这些处理程序和方法真正决定了页面的行为。可以使用 ＜script runat=server＞ 标记对此代码进行内联定义，或者将其放置在外部类（代码分离类）中。代码分离类是从 Page 继承并使用额外的方法的类，被指定用作 HTTP 处理程序的基类。
  
  　　还有一种情况，HTTP 处理程序也不是基于 Page 的，即在应用程序配置文件的 ＜pages＞ 部分中，包含了 PageBaseType 属性的重新定义。
  
  ＜pages PageBaseType="Classes.MyPage, mypage" /＞
  
  　　PageBaseType 属性指明包含页面处理程序的基类的类型和程序集。从 Page 导出的这个类可以自动赋予处理程序扩展的自定义方法和属性集。
  
  　　页面的生命周期
  
  　　完全识别 HTTP 页面处理程序类后，ASP.NET 运行时将调用处理程序的 ProcessRequest 方法来处理请求。通常情况下，无需更改此方法的实现，因为它是由 Page 类提供的。
  
  　　此实现将从调用为页面构建控件树的 FrameworkInitialize 方法开始。FrameworkInitialize 方法是 TemplateControl 类（Page 本身从此类导出）的一个受保护的虚拟成员。所有为 .aspx 资源动态生成的处理程序都将覆盖 FrameworkInitialize。在此方法中，构建了页面的整个控件树。
  
  　　接下来，ProcessRequest 使页面经历了各个阶段：初始化、加载视图状态信息和回发数据、加载页面的用户代码以及执行回发服务器端事件。之后，页面进入显示模式：收集更新的视图状态，生成 HTML 代码并随后将代码发送到输出控制台。最后，卸载页面，并认为请求处理完毕。
  
  　　在各个阶段中，页面会触发少数几个事件，这些事件可以由 Web 控件和用户定义的代码截取并进行处理。其中的一些事件是嵌入式控件专用的，因此无法在 .aspx 代码级进行处理。
  
  　　要处理特定事件的页面应该明确注册一个适合的处理程序。不过，为了向后兼容早期的 Visual Basic 编程风格，ASP.NET 也支持隐式事件挂钩的形式。默认情况下，页面会尝试将特定的方法名称与事件相匹配，如果实现匹配，则认为此方法就是匹配事件的处理程序。ASP.NET 提供了六种方法名称的特定识别，它们是 Page_Init、Page_Load、Page_DataBind、Page_PreRender 和 Page_Unload。这些方法被认为是由 Page 类提供的相应事件的处理程序。HTTP 运行时会自动将这些方法绑定到页面事件，这样，开发人员就不必再编写所需的粘接代码了。例如，如果命名为 Page_Load 的方法绑定到页面的 Load 事件，则可省去以下代码。
  
  this.Load += new EventHandler(this.Page_Load);
  
  　　对特定名称的自动识别是由 @Page 指令的 AutoEventWireup 属性控制的。如果该属性设置为 false，则要处理事件的所有应用程序都需要明确连接到页面事件。不使用自动绑定事件的页面性能会稍好一些，因为不需要额外匹配名称与事件。请注意，所有 Microsoft Visual Studio? .NET 项目都是在禁用 AutoEventWireup 属性的情况下创建的。但是，该属性的默认设置是 true，即 Page_Load 等方法会被识别，并被绑定到相关联的事件。
  
  　　下表中按顺序列出了页面的执行包括的几个阶段，执行的标志是一些应用程序级的事件和/或受保护并可覆盖的方法。
  
  表 1：ASP.NET 页面生命中的关键事件
  
  阶段 页面事件 可覆盖的方法
  页面初始化 Init
  加载视图状态 LoadViewState
  处理回发数据 任意实现 IPostBackDataHandler 接口的控件中的 LoadPostData 方法
  加载页面 Load
  回发更改通知 任意实现IPostBackDataHandler接口的控件中的RaisePostDataChangedEvent 方法
  处理回发事件 由控件定义的任意回发事件 任意实现 IPostBackDataHandler 接口的控件中的 RaisePostBackEvent 方法
  页面显示前阶段 PreRender
  保存视图状态 SaveViewState
  显示页面 Render
  卸载页面 Unload
  
  　　以上所列的阶段中有些在页面级是不可见的，并且仅对服务器控件的编写者和要创建从 Page 导出的类的开发人员有意义。Init、Load、PreRender、Unload，再加上由嵌入式控件定义的所有回发事件，就构成了向外发送页面的各个阶段标记。
  
  
  

原文转自：http://www.ltesting.net