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

 

其實對於這些比較底層的研究，還是外國人來的深入與具體。我在上面貼的幾個引用，裡面也太量引用了老外的文章，有實力的一定要看看，不會有壞處的！