Page 的生命周期学习小结

(以前我在 csdn 写的翻译文章,现在转到这里来。)

Page 的生命周期学习小结

原文链接:Page Events: Order and PostBack
作者:Paul Wilson
翻译:木野狐

初始化(Initialization)

页面被请求时,第一个被执行的总是构造函数(constructor). 你可以在这里初始化很多自定义属性或对象。不过这里有一些限制,因为 page 还没有被完全初始化。特别地,你必须使用 HttpContext.Current 来访问 QueryString, Form, Cookies 集合,以及 Cache 对象。而 Session 对象在 constructor 里是无法访问的。

下面接着执行的是 AddParsedSubObject 方法,这个方法把组成该 page 的所有子控件添加到控件集合树中。在很多高级的页面模板解决方案中,该方法通常被覆盖,以便把页面的控件添加到一个特殊的页面模板中去。该方法递归的被子控件调用,所有这些子控件都是这时候初始化的,从最里面的开始。

接着是 DeterminePostBackMode 方法。该方法允许你影响 IsPostBack 的值,以及相关事件。如果你想从数据库中加载 ViewState 以便 redirect 时,这个可能对你有用。因为 ViewState 仅仅在 IsPostBack 为 true 的时候被恢复。
你可以通过返回 null 来强制不 postback, 或者返回 Request.Form 来强制 postback. 这个方法是不推荐使用的,除非是在特殊的情况下,因为他还影响其他的事件。

然后是 OnInit 方法。通常这是我们使用到的第一个方法。这时,所有控件已经被初始化,也就是说所有原始值都被设定了。而 ViewState 以及所有其他 post 的值还没有被应用到控件上。也就是说这时候所有通过代码或者用户操作做的更改还没有被恢复。这通常是创建或重新创建动态控件的最佳时机。

恢复和加载(Restore and Load)

接下来的 LoadPageStateFromPersistenceMedium 方法,仅仅在 PostBack 时被执行。当你要改变保存 ViewState 的方法时(使用 Session 或其他自定义的储存方法),覆盖这个方法,以及后面的 SavePageStateToPersistenceMedium 方法。注意:该方法并不真正加载 ViewState 到 page 及其子控件。

ViewState 被取回后,接着 LoadViewState 方法将它们恢复到 page, 并递归的恢复到每一个子控件(只有 PostBack 的那些).这时,每个控件已经被恢复到了它上次执行时的状态,但用户 post 的值还没有被应用。因为这属于 ViewState. 这个方法是恢复所有在事件中创建的动态控件的最好时机。

下一个是 ProcessPostData 方法。仅仅在 PostBack 时被执行。而且这个方法不能被覆盖,因为它是页面基类中实现的一个私有方法。这个方法最终将用户 post 的值,通过匹配控件的名称的方法,恢复到页面。这时,page 已经被完全恢复了。动态控件必须在这个方法之前被创建。这个方法同时也为稍后的 changed 事件记录控件值的改变。

然后才是 OnLoad 方法。大部分的代码中都使用这个方法,因为这是在 page 的生命周期中,第一个所有的值都被恢复了的地方。我们可以通过检查 IsPostBack 属性来避免不必要的重设状态。同时也可以检查 IsValid 属性来进行验证。同时还可以在这里创建动态控件。所有这些控件的方法都会被执行并捕获,包括 ViewState. 但回发的值不可以。

Raised Events

下一个方法,ProcessPostData 方法, 实际上是前面那个方法的第二个入口(second pass)。它仅仅处理回发,而且由于是私有方法,所以不能被覆盖。这个方法显得有些奇怪,但又是必要的。因为在 OnLoad 方法中重建的动态控件需要他们回发的值。所有在这个方法之后创建的动态控件,将只能恢复 ViewState, 而不能恢复回发的值,并且不能触发任何更改事件。

下一个方法, RaiseChangedEvents, 同样仅仅用于回发时。它是一个基类实现的私有方法。这时 changed 事件被真正触发。这基于前面 ProcessPostData 方法中标注出回发的值的差异。当有多个 changed 事件被触发时,其先后顺序是没有保证的。

下面是 RaisePostBackEvent 方法。仅用于回发,而且是基类实现的私有方法。这是真正提交 form 的方法,除非是 postback。比如按钮,或者其他通过 javascript 提交的控件被触发。如果使用了 Validators, 如没有手动调用 Validate 方法,这时也已经被调用了。有时候 ie 的 bug 会使得表单被提交,而不引发事件。

接着是 OnPreRender 方法。这通常是在被绘制到浏览器之前,要更改 page 及其子控件的最后机会。你也可以在这里创建动态控件。但这时只能捕获 ViewState, 而不能接受 posted values, 而且没有事件。因为上面提到的 ie 的 bug, 这里可以用来捕获没有触发事件的 post back.

保存和绘制(Save and Render)

下一个是 SaveViewState 方法。 不管是否 post back. 递归的应用到每一个子控件。ViewState 一般保存所有和 aspx 页面里不一样的属性,不管是被代码还是用户更改的。注意,由于控件的值是通过他们在控件树中的位置来保存的,所以如果在这之后添加动态控件到错误的位置, ViewState 可能会崩溃。

下面是 SavePageStateToPersistenceMedium 方法。它真正的保存 page 的 ViewState. 这个方法可覆盖。如果重写的话,注意这里由于 asp.net 的 bug, 需要手工设定一下 __VIEWSTATE,哪怕是空值。

接着是 Render 方法。它递归的调用到每个子控件,真正的绘制各自的 html, 发送到浏览器。在一些页面模板方案中,常常在这里添加通用的 header 和 footer. 而不用使用服务器控件。 注意在这里能作的更改必须是纯的 html. 因为这时候控件都已经绘制完了。

最后是 OnUnload 方法。它调用了 Dispose 方法。这个方法可以用来清理页面中使用的非托管资源。特别是类似于关闭打开的文件或数据库连接等。该方法只有当页面已经被发送到客户端浏览器后才发生。所以它只能对服务端的对象起作用。所以他不能在 page 的 trace 中被显示。

上面就是 page 的生命循环。每次有一个新的请求时,以上过程就重复一次。

Listing 1: Page 的事件小结
 
Method PostBack Controls
Constructor Always All
AddParsedSubObject Always All
DeterminePostBackMode Always Page
OnInit Always All

LoadPageStateFromPersistenceMedium PostBack Page
LoadViewState PostBack All
ProcessPostData1 PostBack Page
OnLoad Always All

ProcessPostData2 PostBack Page
RaiseChangedEvents PostBack Page
RaisePostBackEvent PostBack Page
OnPreRender Always All

SaveViewState Always All
SavePageStateToPersistenceMedium Always Page
Render Always All
OnUnload Always All

posted on 2006-01-19 11:07  NeilChen  阅读(458)  评论(0编辑  收藏  举报

导航