asp.net的ViewState学习
这些还是前辈们都研究烂的东东,我也只是COPY他们的成果,好了,什么也不说了,先来一张表:
页面事件 | ViewState相关操作 |
PreInit | 设置控件静态属性 |
Init | 执行TrackViewState方法(打开ViewState跟踪) |
InitComplete | |
从_ViewState隐藏字段更新控件属性,因为控件属性大部分实际存储在ViewState中,所以也可以说是恢复/更新ViewState,并对 恢复/更新过的ViewSate标记为Dirty | |
从回传的PostData值中更新控件属性 | |
PreLoad | |
Load | |
再次从回传的PostDataw值中更新控件属性 | |
LoadComplete | |
PreSender | |
PreSenderComplete | |
执行SaveViewState方法(所有标记为Dirty的ViewState被存储下来) | |
Sender | |
Unload |
还是说下自己的心得吧。为什么我们这么关心ViewState,能方便我们编程,这只是其一,其二就是如果我们不注意,ViewState也许会我们的应用程序带来负面影响。最主要的就是使页面的体积“无限增大”。而实际上这有很多都是可以避免的!
在ViewState的生命周期中(请允许我这么说),哪一阶段最值得注意?我认为是执行TrackViewState方法的时候。当执行了这个方法,就意味着在今后任意对控件状态的修改都会被ViewState记录,而这也是页面体积“无限增大”的源泉。
ViewState的理念是什么?是变,任何变化都逃不出ViewState的眼睛!
如果我们想编出一个性能优秀的作品,一定不会放过对ViewState的优化,特别是对那些静态数据,它们仅仅只是起显示作用,并不会得到修改。所以,针对以上两个特点,我们就有两个解决方案:要么不用ViewState,要么在TrackViewState方法执行之前对值进行变化。
我们在对页面进行编程前,需要对页面进行一次分析,哪些数据是仅供显示的静态数据,哪些数据是需要用户来完成交互的动态数据。我们要做的,仅是让ViewState记录那些进行交互的状态就可以了。
当然,上面说的实在太理想化,但这却是我们做Asp.net的原则之一,尽力往上面靠就好了。
看过一个数字,说ViewState在页面中不要超过30%,或者不要超过30K,不然性能一般不太好。我虽然对这个数字不太感冒,但是尽力缩小ViewState,却是我们每个Asp.net程序员义不容辞的责任啊!
参考的文章:
1.对viewstates的理解更深入了(1)
http://blog.csdn.net/orichisonic/archive/2008/10/15/3078994.aspx
2.对viewstates的理解更深入了(2)
http://blog.csdn.net/orichisonic/archive/2008/10/15/3078996.aspx
3. 真正理解ASP.NET的ViewState (Truly Understanding ViewState) 很有名的一篇译文
http://blog.csdn.net/vividboy/archive/2008/01/28/2069347.aspx
4.ASP.NET开发人员必读──关于ViewState和动态控件的帖子
http://blog.joycode.com/saucer/archive/2006/09/28/84379.aspx
其实对于这些比较底层的研究,还是外国人来的深入与具体。我在上面贴的几个引用,里面也太量引用了老外的文章,有实力的一定要看看,不会有坏处的!