2、Session 在Asp.Net內部，有一個StateApplication來管理Session，實際上就是一個輔助進程，處理Session到期、建立的特殊請求，在收到每一次請求的時候，輔助進程就會調用狀態伺服器（可以通過Web.config設定不同的狀態伺服器）來擷取Session，如果沒有對應該SessionId的Session，則會建立一個，然後綁定到上下文中（HttpContext）；與Asp不同的是，Session的狀態伺服器有多種，目前在Asp.Net內部實現了三種：
1) InProcStateClientManager 這是傳統的Session儲存方式，但是還是有些細微差別
2) SqlStateClientManager 這是將Session儲存到資料庫方式
3) OutOfProcStateClientManager 這是將Session儲存到進程外的方式
Asp.Net的Session機制有一個特點，就是處理Session的輔助進程與儲存Session的狀態伺服器是分開的，按照MSDN的說法，有下列好處：
“因為用於工作階段狀態的記憶體不在 ASP.NET 輔助進程中，所以可以實現從應用程式故障的恢複。”
“因為所有狀態與輔助進程不儲存在一起，您可以乾淨地跨多個進程對應用程式進行分區。這種分區可以顯著地提高多個進程的電腦上應用程式的可用性和可縮放性。”
“因為所有狀態與輔助進程不儲存在一起，所以您可以跨運行於多個電腦上的多個輔助進程對應用程式進行分區。”
Asp.Net的Session機制個人觀點，感覺靈活性比較好，內部實現也比較巧妙，但是實際上因為沒有做過多的測試，所以應用上會不會像它說的那麼美好，不敢打包票。有機會，我會單獨寫篇文章來深入的探討Asp.Net 內部的Session機制。
3、Cookie 這個沒甚麼好說，實際上Asp.Net與Asp的Cookie沒甚麼分別，也許這項技術毀譽參半，而且比較依賴客戶機實現，MS也沒什麼改進的。
4、ViewState 這是我們今天重點討論的；實際上ViewState並不神秘，就是一個Hidden欄位，但是它是伺服器控制項狀態儲存的基礎；不熟悉的朋友可以用IE查看Html源碼，找到一個名為"__VIEWSTATE"的Hidden欄位，其中有一大堆亂七八糟的字元，這就是頁面的ViewState。
做過Web程式的人可能都有這種痛苦的體會，有時候為了處理頁面上面比較複雜的功能，常常會加很多Hidden，然後在伺服器端用一大堆判斷來分析目前的狀態，寫起來煩人，寫完了代碼更是難看；實際上，ViewState就是幫我們系統的實現了儲存控制項狀態的功能，伺服器端控制項能夠在多次請求間儲存狀態也全靠它。
好，介紹就到這裡，今天我們不是討論ViewState的使用，而是從內部來探探這個東西的本質。
我們首先建一個測試的頁面：
<%@ Page language="c#" Codebehind="ViewStateTest.aspx.cs" AutoEventWireup="false" Inherits="CsdnTest.ViewStateTest" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<html>
<head>
<title>ViewStateTest</title>
<meta name="GENERATOR" Content="Microsoft Visual Studio 7.0">
<meta name="CODE_LANGUAGE" Content="C#">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">
</head>
<body>
<form id="ViewStateTest" method="post" runat="server">
<asp:Button ID="btnPostBack" Runat="server" Text="Post Back" Width="85px"></asp:Button>
<br/>
<asp:CheckBox ID="chkTest" Runat="server" Text="This is a check box"></asp:CheckBox>
</form>
</body>
</html>
這是用Vs.Net設計出來的一個簡單的頁面，裡麵包含了一個伺服器端的按鈕和一個CheckBox，然後我們在伺服器端響應按鈕的事件：
private void btnPostBack_Click(object sender, System.EventArgs e)
{
[1] Response.Write( "ViewState :"+Request.Params["__VIEWSTATE"]+"<br/>" );
[2] string decodeValue = Encoding.UTF8.GetString( Convert.FromBase64String( Request.Params["__VIEWSTATE"] ) );
[3] Response.Write( "ViewState decode :"+decodeValue+"<br/>" );
[4] object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
[5] Response.Write( "ViewState Object :"+viewstate.GetType().Name );
}
為了方便看，我加上了行號；第一行我們把ViewState的值打出來，第二行是什麼呢？實際上ViewState儲存到用戶端的一串字串就是內部的ViewState通過某種方式序列化之後再經過Base64編碼得來的，所以我們把Base64編碼的字串反編碼一次再打出來；至於第四行，我先不說，先看執行結果：
運行之後，頁面上什麼都沒有，除了按鈕和CheckBox（廢話 ：）），我們點擊按鈕，然後結果如下：
[A] ViewState :dDwxMjU2MDI5MTA3OztsPGNoa1Rlc3Q7Pj6Gg0Qzm+7gacYWcy0hnRCT9toOdA==
[B] ViewState decode:t<1256029107;;l>D3i s-! t
[C] ViewState Object :Triplet
然後我們來分析這個結果，A中顯示的就是ViewState傳到用戶端的值，B中顯示的是通過Base64反編碼之後的值，從這裡面好像還是看不出什麼，C中出現了一個:Triplet ？這是什麼呢，我們回到上面的代碼：
object viewstate = (new LosFormatter()).Deserialize( Request.Params["__VIEWSTATE"] );
注意我們使用了一個LosFormatter類，實際上這個類就是Asp.Net內部為ViewState提供序列化的類，它有兩個方法，一個是Serialize，就是序列化一個對象，一個是Deserialize，是還原序列化，我們這裡使用了還原序列化的方法來把ViewState直接還原序列化成一個對象，然後把這個對象的類型打出來，這個對象就是:Triplet類型，實際上Asp.Net中頁面儲存的ViewState就是這個類型，我們先分析一下LosFormater，再來細說.
我們再回來看打出來的結果B：t<1256029107;;l>D3i s-!
t，實際上通過查看LosFormatter反編譯後的代碼，大致上可以看出它序列化的方式是很簡單的，就是判斷要序列化對象的類型，如果不是直接序列化的類型，則把它的類型記錄下來，然後在遞迴序列化它的屬性，我們看B中的"t"就是表示Triplet這個類型，這個類型有三個屬性，這三個屬性包含在"<"和">"之間，用";"分割，而最後面的D3i s-!
t據我分析應該是一個防止ViewState被改變的Hash值，這個不是很確定，因為反編譯的代碼實在是很難看，我只是瞭解之後就沒仔細看了。
我們剛剛分析出來Page中的ViewState還原序列化之後是Triplet這個類型，實際上這個類在MSDN中就查得到，它就是一個包含了三個對象的對象，說簡單點，它就是一個能放三個箱子的大箱子（好像還是說的比較糊塗，呵呵），它有三個屬性：First、Second、Thrid ：），分別代表三個對象。
對應到Page當中，First是Page.GetTypeHashCode()的傳回值，這個方法是System.Web.UI.Page定義的一個保護的虛擬方法，返回一個整型，由Aspx檔案產生的類來實現的，因為這個類是有Asp.Net負責在運行期產生原始碼並編譯，它會計算出一個大常量作為傳回值，這個傳回值在整個Web應用程式所有的Page中是唯一的。（提一句題外話，Asp.Net自動產生的原始碼可以到 系統硬碟:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\Temporary ASP.NET Files下面去找），這個唯一的Hash值是為了在ViewState中產生一個標記，使這個ViewState只適用與對應的頁面。
Second則是通Control.SaveViewStateRecursive方法遞迴儲存頁面控制項樹的ViewState返回的對象，也就是真正的ViewState的資料。
Third中儲存的是當前頁面需要PostBack的控制項名的列表。
分析了頁面的ViewState的構成，我們再來看Control的ViewState的實現。ViewState是System.Web.UI.Control類實現的一個屬性，這個屬性的類型是System.Web.UI.StateBag，這個類就包含了ViewState資料結構的實現，實際上它的內部也就是個Hash表，通過Key值來儲存和檢索資料。
那麼伺服器控制項是怎麼實現儲存狀態的呢？
我們知道，所有的伺服器控制項都是從System.Web.UI.Control派生的，所以都擁有ViewState這個屬性，在Control內部，定義了兩個Protected的虛擬方法：
protected virtual object SaveViewState()
和
protected virtual void LoadViewState(object savedState)
這兩個方法是給子控制項派生用來儲存和讀取自己的ViewState的，比如我們有一個自己寫的控制項，往ViewState中儲存了一個字串，那麼我們的方法大致像這樣：
protected virtual object SaveViewState()
{
object[] states = new object[2];
states[0] = base.SaveViewState(); //記得儲存父控制項的ViewState
states[1] = "Hello,I'm timmy!"; //這裡儲存我們自己的
return states; //返回重新封裝後的儲存對象
}
擷取的時候：
protected override void LoadViewState(object savedState) //這裡的savedState就是我們Save的時候return 的object數組
{
object[] states = (object[])savedState;
base.LoadViewState( states[0] ); //把父類的資料給他自己去解析
string myData = (string)states[1]; //擷取我們自己的資料
}
我們可以按照自己的方式來儲存，不一定非要像上面這樣用數組，實際上我們可以用任何支援序列化的對象都可以，父類並不關心子類如何儲存，我們只要在Save和Load的時候使用同樣的方式，並且把正確的資料傳遞給父類方法就可以了。
另外，還有一個問題就是我們使用的Control的ViewState是Key-Value這樣的索引值對，那它是怎麼儲存的呢？
實際上很簡單，System.UI.Web下面有一個類叫Pair，呵呵，這個和Triplet差不多，只是它裡面只有兩個對象。StateBag儲存的時候，First會存放所有Key值的數組，Second則存放所有Value的數組。
到現在，我們瞭解了ViewState是如何序列化並且儲存到用戶端，也瞭解了控制項怎麼儲存自己的ViewState，那麼這二者是怎麼結合的呢？
也就是整個頁面的控制項樹的ViewState是怎麼儲存和讀取的呢？
在Control內部有兩個internal的方法：
internal object SaveViewStateRecursive()；
internal void LoadRecursive()；
這兩個方法由System.Web.UI.Page來調用，Page在Render結束後就會調用SavePageViewState方法，SavePageViewState方法會調用Control的SaveViewStateRecursive()方法，這個方法就是通過遞迴調用每一個Control.Controls的SaveViewStateRecursive方法來儲存控制項樹中所有控制項的ViewState。到這裡，可能聰明的朋友要問了，既然SaveViewStateRecursive是遞迴調用儲存的方法，那麼我們上面寫的SaveViewState()方法又有什麼用呢？
我們知道，Control.Controls可能會有很多個，而且我們的SaveViewState()只儲存了當前控制項的資料，而沒有記錄控制項樹的結構，那麼如果我們遞迴SaveViewState()方法來儲存資料的話，那麼控制項樹的結構就會丟失，那麼Load的時候就沒辦法還原了，實際上在SaveViewStateRecursive方法中大致的代碼是這樣：
[1] 擷取控制項自己的ViewState（調用SaveViewState方法）
[2] 迴圈子控制項
{
定義兩個動態數組，一個儲存控制項的索引，一個儲存遞迴調用子控制項SaveViewStateRecursive方法返回的值
}
[3] 定義一個Triplet（呵呵，這個東西又出現了）
[4] First儲存本控制項的ViewState
[5] Second儲存子控制項的索引
[6] Third儲存遞迴子控制項SaveViewStateRecursive方法的傳回值
[7] 返回Triplet
這樣就儲存了整個控制項樹的ViewState和控制項樹的結構
Load的方式與Save差不多，只是Load的時候會從savedState中擷取子控制項的索引來依次遞迴子控制項的LoadRecursive()方法，這樣才能保證正確的把儲存的資料傳給子控制項。
到這裡，ViewState的實現我們大致瞭解了一下，最後得出一些結論：
1、ViewState是存放在用戶端，因此會減輕伺服器的負擔，是一種比較好的儲存資料的方式。
2、因為ViewState本身的限制，只能儲存可以序列化的對象，而且最好不要放太多東西，能省則省，以免在減慢傳輸的速度，以及加重伺服器解析的負擔。
3、我們通過很簡單的方式就可以把ViewState裡面的值擷取出來，我們上面討論了一些，雖然沒有把解析的代碼寫出來，但是利用LosFormatter可以得到ViewState還原序列化後的對象，那麼要解析出來簡直是易如反掌；所以ViewState在安全性上面還是比較差，建議不要
存放比較機密和敏感的資訊，儘管ViewState可以加密，但是由於ViewState要儲存在用戶端，天生就有安全性的隱患。
4、實際從技術角度，ViewState沒有任何新意，但是結合伺服器控制項的設計還是很巧妙的。
最後，以我個人的觀點，我覺得ViewState的出現很大程度上減輕了程式員的負擔，但是要看清的是ViewState的本質，合理的應用它。
匆忙寫就難免有很多問題，還希望大家多提意見，不足之處請多指教！
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
