ASP.NET Web Page应用深入探讨

　　一、服务器脚本基础介绍

　　首先，我们先复习一下Web服务器页面的基本执行方式：

　　1、客户端通过在浏览器的地址栏敲入地址来发送请求到服务器端

　　2、服务器接收到请求之后，发给相应的服务器端页面（也就是脚本）来执行，脚本产生客户端的响应，发送回客户端

　　3、客户端浏览器接收到服务器传回的响应，对Html进行解析，将图形化的网页呈现在用户面前

　　对于服务器和客户端的交互，通常通过下面几种主要方式：

　　1、Form：这是最主要的方式，标准化的控件来获取用户的输入，Form的提交将数据发送给服务器端处理

　　2、QueryString：通过在Url后面带参数达到将参数传送给服务器，这种方式其实跟Get方式的Form是一样的

　　3、Cookies：这是一种比较特殊的方式，通常用于用户身份的确认

　　二、ASP.Net简介

　　传统的服务器脚本语言，如ASP、JSP等，编写服务器脚本的方式大同小异，都是在Html中嵌入解释或编译执行的代码，由服务器平台执行这些代码来生成Html；对于这类似的脚本，页面的生存周期实际上很简单，就是从开头至末尾，执行完所有的代码，当然用Java编写的Servlet可以编写更复杂的代码，但是从结构上看，和JSP没什么区别。

　　ASP.Net的出现，打破了这种传统；ASP.Net采用了CodeBehind技术和服务器端控件，加入了服务器端的事件的概念，改变了脚本语言编写的模式，更加贴近Window编程，使Web编程更加简单、直观；但是我们要看到，ASP.Net本身并没有改变Web编程的基本模式，只是封装了一些细节、提供了一些易用的功能，使代码更容易编写和维护；从某种程度上来说，将服务器端执行的方式复杂化了，这就是我们今天要讨论的主体：ASP.Net Web Page的生存周期。

　　三、ASP.Net请求处理模式

　　我们说，ASP.Net的Web Page并没有脱离Web编程的模式，所以它仍然是以 请求->接收请求->处理请求->发送响应 这样的模式在工作，每一次与客户端的交互都会引发一次新的请求，所以一个Web Page的生命周期是以一次请求为基础的。

　　当IIS收到客户端的请求的时候，会将请求交给aspnet_wp这个进程来处理，这个进程会查看请求的应用程序域是否存在，如果不存在则会创建一个，然后会创建一个Http运行时（HttpRuntime）来处理请求，这个运行时“为当前应用程序提供一组 ASP.NET 运行时服务”（摘自MSDN）。

　　HttpRuntime在处理请求的时候，会维护一系列的应用程序实例，也就是应用程序的Global类（global.asax）的实例，这些实例在没有请求的时候，会存放在一个应用程序池中（实际上应用程序池由另一个类来维护，HttpRuntime只是简单的调用），每接收到一个请求，HttpRuntime都会获取一个闲置的实例来处理请求，这个实例在请求结束前不会处理其他的请求，处理完毕之后，它又会回到池中，“一个实例在其生存期内被用于处理多个请求，但它一次只能处理一个请求。”（摘自MSDN）

　　当应用程序实例处理请求的时候，它会创建请求页面类的实例，执行它的ProcessRequest方法来处理请求，这个方法也就是Web Page生命周期的开始。

　　四、Aspx页面与CodeBehind

　　在深入了解页面的生命周期之前，我们先来探讨一些Aspx与CodeBehind之间的关系。

<%@ Page language="c#" Codebehind="WebForm.aspx.cs" Inherits="MyNamespace.WebForm" %>

　　相信使用过CodeBehind技术的朋友，对ASPX顶部的这句话应该是非常熟悉了，我们来一项一项的分析它：

　　Page language="c#" 这个就不用多说了吧

　　Codebehind="WebForm.aspx.cs" 这一句表示绑定的代码文件

　　Inherits="MyNamespace.WebForm" 这句非常重要，它表示页面继承的类名称，也就是CodeBehind的代码文件中的类，这个类必须从System.Web.WebControls.Page派生

　　从上面我们可以分析出，实际上CodeBehind中的类就是页面（ASPX）的基类，到这里，可能有些朋友要问了，在编写ASPX的时候，完全是按照ASP的方式，在Html中嵌入代码或者嵌入服务器控件，没有看到所谓“类”的影子啊？

　　这个问题实际上并不复杂，各位使用ASP.Net编程的朋友可以到你们的系统盘：\WINDOWS\Microsoft.NET\Framework\<版本号>\Temporary ASP.NET Files这个目录下，这个下面就放了所有本机上存在的ASP.Net应用程序的临时文件，子目录的名称就是应用程序的名称，然后再下去两层（为了保证唯一，ASP.Net自动产生了两层子目录，并且子目录名称是随机的），然后我们会发现有很多类似：“yfy1gjhc.dll”、“xeunj5u3.dll”这样的链接库以及“komee-bp.0.cs”、“9falckav.0.cs”这样的源文件，实际上这就是ASPX被ASP.Net动态编译后的结果，打开这些源文件我们可以发现：

public class WebForm_aspx : MyNamespace.WebForm, System.Web.SessionState.IRequiresSessionState

　　这就印证了我们前面的说法，ASPX是代码绑定类的子类，它的名称是ASPX文件名加上“_aspx”后缀，通过研究这些代码我们可以发现，实际上所有aspx中定义的服务器控件都是在这些代码中生成的，然后动态产生这些代码的时候，把原来在ASPX中嵌入的代码写在了相应的位置。

　　当某个页面第一次被访问的时候，Http运行时就会使用一个代码生成器去解析ASPX文件并生成源代码并编译，然后以后的访问就直接调用编译后的dll，这也是为什么ASPX第一次访问的时候非常慢的原因。

　　解释了这个问题，我们再来看另一个问题。我们在使用代码绑定的时候，在设计页面拖一个控件，然后切换到代码视图，就可以直接在Page_Load中使用这个控件了，既然控件是在子类中产生的，那为什么在父类中可以直接使用呢？

　　实际上我们可以发现，每当用VS.Net拖一个控件到页面上，代码绑定文件中总是会类似这样的添加一个声明：

protected System.Web.WebControls.Button Button1;

　　我们可以发现这个字段被声明成protected，而且名字与ASPX中控件的ID一致，仔细想一想，这个问题就迎刃而解了。我们前面提到ASPX的源代码是被生成器动态生成和编译的，生成器会产生动态生成每一个服务器控件的代码，在生成的时候，它会检查父类有没有声明这个控件，如果声明了，它会添加类似下面的一句代码：

this.DataGrid1 = __ctrl;

　　这个__ctrl就是生成该控件的变量，这时候它就把控件的引用赋给了父类中相应的变量，这也是为什么父类中的声明必须为protected（实际上也可以为public），因为要保证子类能够调用。

　　然后在执行Page_Load的时候，因为这时候父类的声明已经被子类中的初始化代码赋了值，所以我们就可以使用这个字段来访问对应的控件，了解了这些，我们就不会犯在代码绑定文件中的构造器里使用控件，造成空引用的异常的错误了，因为构造器是最先执行的，这时候子类的初始化还没有开始，所以父类中的字段是空值，至于子类是什么时候初始化我们放到后面讨论。

　　五、页面生存周期

　　现在回到第三个标题中讲到的内容，我们讲到了HttpApplication的实例接收请求，并创建页面类的实例，实际上这个实例也就是动态编译的ASPX的类的一个实例，上一个标题中我们了解到ASPX实际上是代码绑定中类的子类，所以它继承了所有的protected方法。

　　现在我们来看看VS.Net自动生成的CodeBehind类的代码，以此来开始我们对页面生命周期的探讨：

#region Web Form Designer generated code

override protected void OnInit(EventArgs e)
{
　//
　// CODEGEN：该调用是 ASP.NET Web 窗体设计器所必需的。
　//
　InitializeComponent();
　base.OnInit(e);
}

/// <summary>
/// 设计器支持所需的方法 - 不要使用代码编辑器修改
/// 此方法的内容。
/// </summary>

private void InitializeComponent()
{
　this.DataGrid1.ItemDataBound += new System.Web.UI.WebControls.DataGridItemEventHandler(this.DataGrid1_ItemDataBound);

　this.Load += new System.EventHandler(this.Page_Load);
}

#endregion

　　这个就是使用VS.Net产生的Page的代码，我们来看，这里面有两个方法，一个是OnInit，一个是InitializeComponent，后者被前者调用，实际上这就是页面初始化的开始，在InitializeComponent中我们看到了控件的事件声明和Page的Load声明。

　　下面是从MSDN中摘录的一段描述和一个页面生命周期方法和事件触发的顺序表：

　　“每次请求 ASP.NET 页时，服务器就会加载一个 ASP.NET 页，并在请求完成时卸载该页。页及其包含的服务器控件负责执行请求并将 HTML 呈现给客户端。虽然客户端和服务器之间的通讯是无状态的和断续的，但是必须使客户感觉到这是一个连续执行的过程。”

　　“这种连续性假象是由 ASP.NET 页框架、页及其控件实现的。回发后，控件的行为必须看起来是从上次 Web 请求结束的地方开始的。虽然 ASP.NET 页框架可使执行状态管理相对容易一些，但是为了获得连续性效果，控件开发人员必须知道控件的执行顺序。控件开发人员需要了解：在控件生命周期的各个阶段，控件可使用哪些信息、保持哪些数据、控件呈现时处于哪种状态。例如，在填充页上的控件树之前控件不能调用其父级。” “下表提供了控件生命周期中各阶段的高级概述。有关详细信息，请点击表中的链接。”

　　从这个表里面我们可以清楚的看到一个Page从装载到卸载之间调用的方法和触发的时间，接下来我们就深入的对其进行一些分析。

　　看了上面的表，细心的朋友可能要问了，既然OnInit是页面生命周期的开始，而我们在上一讲中谈到控件在子类中被创建，那么在这里实际上在InitializeComponent方法中我们已经可以使用父类中声名的字段了，那么就意味着子类的初始化更在这之前？

　　在第三个标题中我们讲到了页面类的ProcessRequest才是真正意义上的页面声明周期的开始，这个方法是由HttpApplication调用的（其中调用的方式比较复杂，有机会单独撰文来讲解），一个Page对请求的处理就是从这个方法开始，通过反编译.Net类库来查看源代码，我们发现在System.Web.WebControls.Page的基类：System.Web.WebControls.TemplateControl（它是页面和用户控件的基类）中定义了一个“FrameworkInitialize”虚拟方法，然后在Page的ProcessRequest中最先调用了这个方法，在生成器生成的ASPX的源代码中我们发现了这个方法的踪影，所有的控件都在这个方法中被初始化，页面的控件树就在这个时候产生。

　　接下来的事情就简单了，我们来逐步分析页面生命周期的每一项：

　　1、初始化

　　初始化对应Page的Init事件和OnInit方法。

　　如果要重写，MSDN推荐的方式是重载OnInti方法，而不是增加一个Init事件的代理，这两者是有差别的，前者可以控制调用父类OnInit方法的顺序，而后者只能在父类的OnInit后执行（实际上是在OnInit里面被调用的）。

　　2、 加载视图状态

　　这是个比较重要的方法，我们知道，对于每次请求，实际上是由不同的页面类实例来处理的，为了保证两次请求间的状态，ASP.Net使用了ViewState。

　　LoadViewState方法就是从ViewState中获取上一次的状态，并依照页面的控件树的结构，用递归来遍历整个树，将对应的状态恢复到每一个控件上。

　　3、 处理回发数据

　　这个方法是用来检查客户端发回的控件数据的状态是否发生了改变。方法的原型：

public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)

　　postDataKey是标识控件的关键字（也就是postCollection中的Key），postCollection是包含回发数据的集合，我们可以重写这个方法，然后检查回发的数据是否发生了变化，如果是则返回一个True，“如果控件状态因回发而更改，则 LoadPostData 返回 true；否则返回 false。页框架跟踪所有返回 true 的控件并在这些控件上调用 RaisePostDataChangedEvent。”（摘自MSDN）

　　这个方法是System.Web.WebControls.Control中定义的，也是所有需要处理事件的自定义控件需要处理的方法，对于我们今天讨论的Page来说，可以不用管它。

　　4、 加载

　　加载对应Load事件和OnLoad方法，对于这个事件，相信大多数朋友都会比较熟悉，用VS.Net生成的页面中的Page_Load方法就是响应Load事件的方法，对于每一次请求，Load事件都会触发，Page_Load方法也就会执行，相信这也是大多数人了解ASP.Net的第一步。

　　Page_Load方法响应了Load事件，这个事件是在System.Web.WebControl.Control类中定义的（这个类是Page和所有服务器控件的祖宗），并且在OnLoad方法中被触发。

　　很多人可能碰到过这样的事情，写了一个PageBase类，然后在Page_Load中来验证用户信息，结果发现不管验证是否成功，子类页面的Page_Load总是会先执行，这个时候很可能留下一些安全性的隐患，用户可能在没有得到验证的情况下就执行了子类中的Page_Load方法。

　　出现这个问题的原因很简单，因为Page_Load方法是在OnInit中被添加到Load事件中的，而子类的OnInit方法中是先添加了Load事件，然后再调用base.OnInit，这样就造成了子类的Page_Load被先添加，那么先执行了。

　　要解决这个问题也很简单，有两种方法：

　　1） 在PageBase中重载OnLoad方法，然后在OnLoad中验证用户，然后调用base.OnLoad，因为Load事件是在OnLoad中触发，这样我们就可以保证在触发Load事件之前验证用户。

　　2） 在子类的OnInit方法中先调用base.OnInit，这样来保证父类先执行Page_Load

　　5、 发送回发更改通知

　　这个方法对应第3步的处理回发数据，如果处理回发数据返回True，页面框架就会调用此方法来触发数据更改的事件，所以自定义控件的回发数据更改事件需要在此方法中触发。

　　同样这个方法对于Page来说，没有太大的用处，当然你也可以在Page的基础上自己定义数据更改的事件，这当然也是可以的。

　　6、 处理回发事件

　　这个方法是大多数服务器控件事件引发的地方，当请求中包含控件事件触发的信息时（服务器控件的事件是另一个论题，我会在不久将来另外撰文讨论），页面控件会调用相应控件的RaisePostBackEvent方法来引发服务器端的事件。

　　这里又引出一个常见的问题：

　　经常有网友问，为什么修改提交后的数据并没有更改

　　多数的情况都是他们没有理解服务器事件的触发流程，我们可以看出，触发服务器事件是在Page的Load之后，也就是说页面会先执行Page_Load，然后才会执行按钮（这里以按钮为例）的点击事件，很多朋友都是在Page_Load中绑定数据，然后在按钮事件中处理更改，这样做有一个毛病，Page_Load永远都是在按钮事件之前执行，那么意味着数据还没来得及更改，Page_Load中的数据绑定的代码就先执行了，原有的数据又赋给了控件，那么执行按钮事件的时候，实际上获得的是原有的数据，那么更新当然就没有效果了。

　　更改这个问题也非常简单，比较合理的做法是把数据绑定的代码写成一个方法，我们假设为BindData：

private void BindData()
{
　//绑定数据
}

　　然后修改PageLoad：

private void Page_Load( object sender,EventArgs e )
{
　if( !IsPostBack )
　{
　　BindData(); //在页面第一次访问的时候绑定数据
　}
}

　　最后在按钮事件中：

private Button1_Click( object sender,EventArgs e )
{
　//更新数据
　BindData();//重新绑定数据
}

　　7、预呈现

　　最终请求的处理都会转变为发回服务器的响应，预呈现这个阶段就是执行在最终呈现之前所作的状态的更改，因为在呈现一个控件之前，我们必须根据它的属性来产生Html，比如Style属性，这是最典型的例子，在预呈现之前，我们可以更改一个控件的Style，当执行预呈现的时候，我们就可以把Style保存下来，作为呈现阶段显示Html的样式信息。

　　8、保存状态

　　这个阶段是针对加载状态的，我们多次提到，请求之间是不同的实例在处理，所以我们需要把本次的页面和控件的状态保存起来，这个阶段就是把状态写入ViewState的阶段。

　　9、呈现

　　到这里，实际上页面对请求的处理基本就告一段落了，在Render方法中，会递归整个页面的控件树，依次调用Render方法，把对应的Html代码写入最终响应的流中。

　　10、处置

　　实际上就是Dispose方法，在这个阶段会释放占用的资源，例如数据库连接。

　　11、卸载

　　最后，页面会执行OnUnLoad方法触发UnLoad事件，处理在页面对象被销毁之前的最后处理，实际上ASP.Net提供这个事件只是设计上的考虑，通常资源的释放都会在Dispose方法中完成，所以这个方法也变成鸡肋了。

　　我们简单的介绍了页面的生存周期，对于服务器端事件的处理做了不太深入的讲解，今天主要是想大家了解页面执行的周期，对于服务器控件的事件和生存期我会在后续在写一些文章来探讨。

　　这些内容是我在学习ASP.Net的时候对Page研究的一些心得，具体的细节没有很详细的探讨，更多的内容请大家参考MSDN，但是我举了一些初学者常犯的错误和出现错误的原因，希望可以给大家带来启发。