|
| ASP.NET Web Page应用深入探讨(3) |
| 来源：www.ASPCool.com 人气：858 录入时间：2007-11-8 |
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，但是我举了一些初学者常犯的错误和出现错误的原因，希望可以给大家带来启发。
|
| |
|
