介绍ASP.NET页面生命周期


  本文标签:ASP.NET页面生命周期

  ASP.NET页面生命周期

  在面对此类问题的时候,首先问问自己控件的数量,如果数量不多,直接通过设置控件的Visible属性解决问题就是了  。这也就是说,把可能要显示的控件都声明为Visible="false",然后在代码中判断当前应该将哪个显示出来  。

  如果控件比较多,然而还是能分组的,同一时间仅仅显示其中的一组,那么你应该考虑使用MultiView,这样你的工作将会轻松不少  。事实上,能够使用 MultiView解决的,都应该优先考虑使用MultiView解决,这比起自己控制哪一个控件显示哪一个控件隐藏要方便多了  。其实MultiView 所做的,也就是帮你控制控件的显示与隐藏  。

  这样做的性能如何呢?我们关注两方面的问题,一方面是服务器端执行的资源消耗,另一方面是传输的带宽消耗  。我们先来看看服务器端执行的资源消耗吧,我们最常见的消耗应该就是数据控件操作数据库时的消耗了  。在ASP.NET 1.x时代,我们没有数据源控件,所以必须手动进行DataBind(),这也就是说如果不手动执行DataBind()的话就不会进行任何数据操作,因此只要我们记得在数据控件不显示的时候也不要让它执行DataBind()就是了,那样就不会有性能损失  。在ASP.NET 2.0当中,使用数据源控件的话数据控件是会自动DataBind()的,这时候会造成控件隐藏时的资源消耗呢?事实上是不会的,数据控件即使已经定义了 DataSourceID属性,它也仅仅在自己第一次可见时才进行自动DataBind()  。如果数据控件的状态是隐藏的(包括使用MultiView隐藏),它就不会自动进行DataBind()  。因此,在ASP.NET 2.0中使用数据源控件以及MultiView之后其底层过程还是和ASP.NET 1.x手动操作的一样,就是少写一些代码而已  。

  我们接着来看看带宽消耗如何,因为隐藏的控件不输出任何的HTML,因此带宽消耗就是指ViewState了  。控件隐藏后,ViewState是不变的,因此隐藏控件确实比完全不加载控件造成了更多的资源消耗,换取的是该控件的状态得以保存  。一般来说,简单控件隐藏后多出来几十字节的ViewState是可以忽略不计的,整个页面中HTML缩进所需的空格也都几十上百字节了;但如果是复杂控件,拥有大量的ViewState,这时候你真的应该考虑动态加载了  。

  总的来说,面对这类问题时首先判断显示隐藏控件的逻辑是否复杂,控件本身是否复杂  。如果是比较简单的情况,则直接使用 MultiView解决就是了  。如果是复杂的情况,那就应该考虑自己使用控件将此逻辑封装在内,而不是直接在页面上暴露这些复杂性  。关于封装控件的问题,在下一篇文章中再讨论,因此我们继续看下一类问题  。

  既不确定类型也不确定数量的控件

  有时候我们面对前面两类问题都有清晰的思路,但是面对复合问题就感觉很混乱了  。例如还是一个调查问卷的显示,数据来自XML,问题类型包括单选和多选,每一道问题的选项个数也不确定,这时候怎么办呢?foreach嵌套foreach,外层迭代问题内层迭代选项,逐个CheckBox/RadioButton来生成?

  这时候我们需要的是把问题分而治之逐个击破的思想  。既然是上述两类问题的嵌套,我们就应该能够通过嵌套对应的解决方案来实现  。对于这个调查问卷的例子,我们可以用Repeater来迭代问题,先把这个定下来,再考虑模板里面怎么做  。模板里面需要显示的是一个不确定类型的问题,因此模板里面放一个 MutliView,把问题类型的表达式绑定到其ActiveViewIndex属性上,例如单选题就是0多选题就是1  。然后MultiView里面的两个View各自嵌套一个Repeater,第0个Repeater迭代选项并显示为RadioButton,第1个Repeater迭代选项并显示为 CheckBox  。就这样就完成了,我们没写任何一行后台代码,也没有动态创建任何控件  。

  然后我们来分析一下这个解决方案的性能  。对比起动态创建控件,它所使用的控件确实是多了一倍,因为一道问题同时创建了两组选项,一组单选一组多选,只不过其中一组被隐藏了  。然而隐藏掉的那一组唯一的服务器端资源消耗就是创建以及绑定,它们不输出任何的HTML,因为它们的值不会被改变所以也不会输出任何的ViewState,并且它们也不会触发任何事件,因此在对性能没有特别要求的情况下这样的性能损失还是可以接受的  。至少,这比起你自己去研究ASP.NET页面生命周期然后自己写一大段代码来实现动态加载控件要好多了  。
问题与实验

  本系列上一篇文章的问题与实验一直没有解答,现在给出参考答案如下:

  1.为Page增加一个ShowCheckBox的属性:

  1. bool ShowCheckBox {  
  2. get { return (ViewState["ShowCheckBox"] == null) ? 
    false : (bool)ViewState["ShowCheckBox"]; }  
  3. set { ViewState["ShowCheckBox"] = value; }  

  在OnLoad的时候检测ShowCheckBox属性,如果为true则添加上该CheckBox控件  。在Button的 OnClick事件中,设置ShowCheckBox为true,并添加上CheckBox  。记得这两处创建的CheckBox必须拥有一致的ID属性  。

  2. 这是为了让ICallbackEventHandler的处理模型符合ASP.NET页面生命周期的模型  。虽然Callback发生的时候,ASP.NET页面生命周期已经与PostBack不同,然而ICallbackEventHandler还是让Callback模仿了PostBack的页面生命周期  。RaiseCallbackEvent相当于PostBack的Raise PostBackEvent阶段,GetCallbackResult相当于PostBack的PreRender阶段  。前者负责事件响应,后者负责生成返回客户端的HTML代码  。

  这次想和大家讨论的问题是,你觉得你是完美主义者吗?面对上面的调查问卷需求,你会选择我所说的Repeater套MultiView再套Repeater的做法,从而避免写任何一行后台代码,还是会选择自己封装一个控件动态创建所有控件,避免任何不必要的性能损失?