这篇文章经典，看过之后大受启发。值得一看！看来ASP.NET跟JSP其实是一样的，本质上没区别，ASP.NET能做到的JSP一样可以做到，反之亦然。只不过ASP.NET的框架看起来先进一点，不过JSP也在发展，似乎也出现了类似ASP.NET的框架。
一、服务器脚本基础介绍
首先，我们先复习一下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 页框架可使执行状态管理相对容易一些，但是为了获得连续性效果，控件开发人员必须知道控件的执行顺序。控件开发人员需要了解：在控件生命周期的各个阶段，控件可使用哪些信息、保持哪些数据、控件呈现时处于哪种状态。例如，在填充页上的控件树之前控件不能调用其父级。”
“下表提供了控件生命周期中各阶段的高级概述。有关详细信息，请点击表中的链接。”
阶段
控件需要执行的操作；要重写的方法或事件
初始化
初始化在传入 Web 请求生命周期内所需的设置。请参阅处理继承的事件。
Init 事件（OnInit 方法）
加载视图状态
在此阶段结束时，就会自动填充控件的 ViewState 属性，详见维护控件中的状态中的介绍。控件可以重写 LoadViewState 方法的默认实现，以自定义状态还原。
LoadViewState 方法
处理回发数据
处理传入窗体数据，并相应地更新属性。请参阅处理回发数据。
注意 只有处理回发数据的控件参与此阶段。
LoadPostData 方法 如果已实现 IPostBackDataHandler）
加载
执行所有请求共有的操作，如设置数据库查询。此时，树中的服务器控件已创建并初始化、状态已还原并且窗体控件反映了客户端的数据。请参阅处理继承的事件。
Load 事件
（OnLoad 方法）
发送回发更改通知
引发更改事件以响应当前和以前回发之间的状态更改。请参阅处理回发数据。
注意 只有引发回发更改事件的控件参与此阶段。
RaisePostDataChangedEvent 方法 （如果已实现 IPostBackDataHandler）
处理回发事件
处理引起回发的客户端事件，并在服务器上引发相应的事件。请参阅捕获回发事件。
注意 只有处理回发事件的控件参与此阶段。
RaisePostBackEvent 方法 （如果已实现 IPostBackEventHandler）
预呈现
在呈现输出之前执行任何更新。可以保存在预呈现阶段对控件状态所做的更改，而在呈现阶段所对的更改则会丢失。请参阅处理继承的事件。
PreRender 事件 （OnPreRender 方法）
保存状态
在此阶段后，自动将控件的 ViewState 属性保持到字符串对象中。此字符串对象被发送到客户端并作为隐藏变量发送回来。为了提高效率，控件可以重写 SaveViewState 方法以修改 ViewState 属性。请参阅维护控件中的状态。
SaveViewState 方法
呈现
生成呈现给客户端的输出。请参阅呈现 ASP.NET 服务器控件。
Render 方法
处置
执行销毁控件前的所有最终清理操作。在此阶段必须释放对昂贵资源的引用，如数据库链接。请参阅 ASP.NET 服务器控件中的方法。
Dispose 方法
卸载
执行销毁控件前的所有最终清理操作。控件作者通常在 Dispose 中执行清除，而不处理此事件。
UnLoad 事件（On UnLoad 方法）
从这个表里面我们可以清楚的看到一个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，关于ViewState的描述，请参考本人的另一篇文章：
http://expert.csdn.net/Expert/topic/1558/1558798.xml?temp=.2561609
LoadViewState方法就是
