ASP.NET页的生命周期
简介
1.对象初始化
2.加载视图状态数据
3.LoadPostData处理回传数据
4.对象加载对象在Load事件中获得正确的Form。所有的对象首先都被组织在页DOM(ASP.NET中称为控件树)中,并且很容易通过代码或者相对位置(crawling the DOM)来引用。然后对象就可以自由的访问HTML中的客户端属性集,例如width,value,或者visibility。加载时,控件逻辑,如算法、以编程方式设置控件属性、用StringBuilder装配输出字符串都同时被执行。大部分的工作都是在这一阶段完成的。Load 事件能够通过调用OnLoad 来重载,如图3。 图3 OnLoad事件是放置逻辑的理想位置 5.激发RaisePostDataChanged 事件如前所述,这发生在所有实现了IPostBackDataHandler接口的控件被正确的回传数据更新以后。在这个过程中,每个控件都有一个布尔值的标识,标识其自上一次提交后该控件的数据是被更改还是保持原值。然后ASP.NET通过搜索页来寻找任何显示控件数据被更改的标识并激发RaisePostDataChanged。RaisePostDataChanged事件直到Load事件发生后,所有控件被更新后才激发。这保证了在控件被回传数据更新前,其它控件的数据在RaisePostDataChanged事件中没有被手动更改过。 6.处理客户端回传事件当回传更新导致数据改变而引发服务器端事件后,引发回传的对象会在RaisePostBackEvent事件中被处理。这种激发回传的对象往往是其状态改变而引发回传的控件(其autopostback被启用)或者是一个被点击的窗体提交按钮。很多代码都在这个事件中执行,因为这是控制事件驱动逻辑的理想位置。为了保证呈现到浏览器的数据的正确性,在一系列的回传事件后RaisePostBackEvent事件最终被激发。基于一致性的考虑,回传中改变的控件直到这个函数被执行后才被更新。也就是说,被预期事件改变的数据总是在结果页反映出来。RaisePostBackEvent事件可以通过RaisePostBackEvent来捕捉,如图4 图4 RaisePostDataChanged和RaisePostBackEvent由IPostBackDataHandler接口定义 7.对象预呈现对象被预呈现的地方对于那些能够保存到视图或者维持其视图状态的对象来说是最后一次有机会改变的地方。这使得预呈现步骤成为做最后修改的理想位置,例如改变控件属性或改变控件树结构,不用担心因为数据库请求或者视图状态更新而导致对象的变化。预呈现阶段之后,对象改变被锁定并且不能再被保存到页视图状态中。预呈现阶段可以通过重载OnPreRender实现。 8.保存视图状态只有在所有的页面对象的改变都发生后视图状态才被保存。对象状态数据被保存在隐藏<input>对象中,这也是对象状态数据准备呈现到HTML的地方。在SaveViewState事件中,值能够被保存到视图状态对象中,但页面控件的改变并不能保存到其中。可以通过重载SaveViewState实现这个步骤,如图5所示: 图5 在OnPreRender中值被设置给控件。在SaveViewState中,值被设置给视图状态对象。 9.呈现HTMLRender事件通过装配用于浏览器输出的HTML来着手页的创建。在Render事件中,页调用对象使它们呈现为HTML,然后页收集HTML来发送。当Render事件被重载的时候,开发者可以为浏览器创建定制的HTML,此时页面创建的任何HTML都还没有生效。Render 方法用HtmlTextWriter对象作参数并由它产生HTML给浏览器。这里仍然可以作修改,但是这样的修改只会反映到客户(译者注:意即改变只会在HTML呈现中反映而视图状态并无法被改变)。Render 事件可以被重载,如图6(下面)
10.释放当页面的HTML呈现后,对象被释放。在Dispose事件中,你可以清除任何在页面创建中构造的对象或者引用。在这里,所有的处理都已经被执行,你可以安全的释放任何还存在的对象,包括Page对象。Dispose能被重载,如图6. 图6 Render事件通过HtmlTextWriter对象为浏览器产生定制HTML 总结每次我们请求一个ASP.NET页的时候,这个从初始化到释放的过程都同样的被执行。通过理解ASP.NET页的内部执行过程,编写和调试代码的时候就会更加容易和高效(更不用提会碰到更少的让我们灰心的事)。 |