ASP.NET Web Page应用深入探讨第1/2页
一、服务器脚本基础介绍
首先，我们先复习一下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）
处理回发事件 处理引起回发的客户端事件，并在服务器上引发相应的事件。请参阅捕获回发事件。