當前位置：
常見的基礎概念，ViewState、Cookie和Session的描述似乎都太復雜和書面化，沒有達到我想象中的簡單（注1）。既然覺得別人說的不簡單或者讓事情變得更難以理解和應用，那么就該自己進行總結，即是為了自己，也是為了別人（注2）。所以我嘗試從我個人的角度進行分析，希望能起到加深自己理解和減少別人誤解的作用。
概述
1.HTTP協議是無狀態的。Web服務器處理完一次請求后立即斷開連接，因此即使同一訪客同一瀏覽器進程，仍然無法被服務器端識別。
2.請求之間需要共享數據。共享數據后，才可以實現辨別身份、保持狀態、個性化等。即使匿名用戶也有避免重新輸入、復合條件檢索等作用。
請求之間可以通過3種方式達到共享數據的目的： 1.基于頁面：表單元素（ViewState）&URL參數。 2.基于客戶端：cookie。3.基于服務器+客戶端：session。這三種方式與服務器采用那種技術是無關的。
簡單說說這3種方式：ViewState受瀏覽器進程時間限制，無法完成超出瀏覽器進程的狀態保存。cookie可以不受時間限制但受存儲數據大小限制，僅能保存少量數據。session不受時間和大小限制，但受服務器資源限制，因為session無論是存儲在內存、還是以文件或數據庫方式存儲都會對服務器效率造成影響。但只有session才能滿足某些網站在狀態數據存儲的規模和安全性的要求。
1.基于頁面
基于頁面的方式可以在POST訪問時通過表單元素(input hidden)傳遞數據，可以通過在附加URL參數傳遞數據。基于頁面的方式強大的地方在于即使客戶端禁用了cookie或javascript，仍對服務器解析不構成影響。ASP.NET的ViewState只是基于頁面傳遞的一種應用。ASP.NET頁面將整個頁面視為一個包含了所有服務器控件的Web Form，默認的POST的URL只能是當前頁。ViewState原本是可以跨頁傳遞的，但由于ASP.NET頁面模型所限，只能起到POST當前頁面后維護頁面數據的作用。 在開始的ASP.NET事件模型中，你無法POST到其他頁面。Response.Redirect()還是Server.Transfer()都不可以，前者先POST回當前頁后采用頁面重定向，即使你Redirect到自身也還是重定向，后者POST到當前頁后再采用其他頁進行請求處理，雖然返回了其他頁的內容，但瀏覽器中的URL甚至都不會改變。到了ASP.NET 2.0才對客戶端提交表單前通過javascript強制POST到其他頁的方式實現了客戶端POST。而Web Form的action還是當前頁面。可能微軟也從未想過在其他頁面使用ViewState的需要，所以給該屬性設置了protected的保護。可是理論上，基于頁面的方式，無論是通過附加表單元素還是URL參數，都可以達到一致的效果。
不討論ASP.NET這種Web Form模型的弊利，我們如果需要考慮客戶端禁用了Cookie和JavaScript的情況（一般無需考慮），采用基于頁面的方式仍可以幫我們解決兩次請求之間共享數據的目的。 在工作經驗里，曾有一個PHP的多子站點的純信息展示類網站，由于唯一的用戶就是維護該網站的編輯，編輯需要在訪問網站時，對需要修改的地方直接修改，因此采用了ViewState的方式達到目的，根據是否登錄來決定是否加載啟用在線編輯的javascript文件，加載后每個區域雙擊即可彈出編輯框，編輯后即使提交通不過仍可繼續修改而不會丟失信息。
2.基于客戶端
cookie是客戶端技術，服務器采用動態網頁技術可以從客戶端讀取請求附加的cookie和向客戶端傳遞cookie，達到了在請求之間共享數據的目的。cookie的本身有著大小的限制，而即使沒有限制，攜帶過大的cookie對于請求的往返來說也是沉重的負擔。cookie是應用廣泛的維持狀態的方式。由于cookie使用HTTP請求頭和響應頭進行發送和接受，因此是一種服務器無關的技術。
3.基于服務器+客戶端
cookie可以設置過期時間，比基于頁面的技術更靈活，但只憑借客戶端的cookie進行驗證安全性存在隱患，而cookie的存儲大小又有限制，因此利用服務器端進行存儲擴充和驗證，這便是session技術。ASP.NET、PHP等都內置了對session的實現，一些大型的網站和框架也提供了自己的session的實現用于滿足各自的需求。大多數我們所見的網站，都使用了session技術。ASP.NET默認的session使用服務器內存存儲（通過Page.Session屬性使用，通過不同的會話提供程序，也可以用數據庫或其他的方式存儲），PHP默認的方式以服務器端文本存儲（同樣也支持內存或數據庫等自定義方式）。
如何使用？
其實ViewState、Cookie和Session在不同程度上解決不同請求之間的數據共享問題，這3種方式與服務器端采用的是PHP還是ASP.NET無關，這一點尤為重要。ViewState一般采用在頁面表單的源代碼中保存數據，其限制可想而知，不過用來完成類似防止表單出錯重填的功能還是沒問題的。cookie采取在客戶端以文本方式存放，雖然數據大小受限制且安全存在隱患，但存儲少量用戶信息還是足夠用的。session可以看做是對cookie的加強（不考慮基于url的session），在服務器端二次驗證，增強了安全性，利用服務器端資源，可以存儲大量數據。這樣看來，完全搞不懂為什么會出現對某個具體的網站有采用那種方式的糾結心態。
1.ViewState用于共享頁面狀態數據可以考慮，即使服務器端沒有直接支持，只要采用的是動態網頁技術，可以很容易實現。
2.Cookie一般可以滿足用戶ID、角色、個性化信息的簡單存儲。
3.Session對于電子商務類網站或需要通過一系列想到頁面完成某個任務的網站來說較為實用，因為單純使用Cookie這時從存儲數據的大小和安全性上來說，都很難勝任。
服務器端無論是采用ASP.NET還是PHP等，一般都會默認支持Session。但內置的Session可能會有各種各樣的問題，所以不要拿內置的Session來否定Session這種方式的必要性。
一個銷售虛擬游戲物品的網站，雖然同時在線人數不是很多，但由于其單個訂單包含的信息量，Cookie方式是根本無法滿足的。單位內部的查詢網站，采用Cookie存儲用戶ID和角色，完全夠用。
如果一個網站Cookie足可以滿足，那么搞不懂為什么要用Session。如果一個網站Session方式才能滿足需要，搞不懂怎么拋棄Session方式。曾就職于一個以虛擬物品網上交易作為主要業務的公司，其訪客無論是否注冊都可以將商品放入購物車中，很多wow的商品包含很多自定義參數可供客戶調節，無論注冊與否都可以生成預付訂單，對于未注冊用戶，即使關閉瀏覽器的之內，都可以再次訪問時查看加入到訂單中的商品，難以想象不使用session方式如何正常工作。如果說在cookie中只存儲必要的key，再訪問時從服務器中獲取，這本身就是session的定義。
沒有session實際使用的經歷，站在可以使用cookie就可以滿足需求的前提下去研究session方式在某個具體技術下的實現的缺點而直接否定session是沒有意義的，這如同使用扁平結構靜態頁的角度來抨擊樹形結構靜態頁網站的物理結構一樣。
小結
搞清某些技術的局限性，來分析是否滿足我們的實際需求，就不會把目光局限于技術本身的比較上。
所以，不要把簡單的問題搞復雜。實踐重要。本來就是為了在兩次請求之間傳遞狀態數據，無論請求頁面是否是同一頁面，只需要考慮低限度那種方式可滿足即可。如果不了解cookie的基礎知識，請自行baidu或google；如果看了概述就猜到我要說什么，那你在實際工作中有過應用。
關注我們要解決的問題，讓本來簡單的問題簡單。譬如Web服務器上都是靜態文件，URL包含了文件的路徑和文件名，甚至連URL參數都無法處理，只能采取客戶端javascript的偽過濾方式控制內容的顯示。后來的動態網頁技術可以在服務器端處理URL參數并根據請求動態生成內容，而后MVC方式出現，URL從直接對應路徑和文件名到映射Controller和Action。可是兩者的區別只在于看待問題的角度不同，沒有任何一種是另一種完全可以替代的，或者說，重點應該是能否恰到好處的解決問題。不要討論Web Form和ASP.NET MVC哪個好，在PHP早就可以任意匹配邏輯結構和物理結構，動態技術是否支持URL映射只是邏輯結構和物理結構映射的問題（幾年前寫一個只通過一個入動態頁入口，實現多個站點的方式，邏輯結構是分類+文章名，訪問時URL也是如此，但物理結構只有一個PHP文件作為入口，所有內容全部存儲在mysql數據庫中，因為需求要求可以通過數據庫備份整個網站，可以直接在幾十個網站中執行對內容的批量操作，讓我對邏輯結構和物理結構的映射一下子所得甚多），影響不到你對業務模型的抽象，對行為接口的提取和對業務流程的處理。
注1：簡單原則；注2：行動原則。
概述
1.HTTP協議是無狀態的。Web服務器處理完一次請求后立即斷開連接，因此即使同一訪客同一瀏覽器進程，仍然無法被服務器端識別。
2.請求之間需要共享數據。共享數據后，才可以實現辨別身份、保持狀態、個性化等。即使匿名用戶也有避免重新輸入、復合條件檢索等作用。
請求之間可以通過3種方式達到共享數據的目的： 1.基于頁面：表單元素（ViewState）&URL參數。 2.基于客戶端：cookie。3.基于服務器+客戶端：session。這三種方式與服務器采用那種技術是無關的。
簡單說說這3種方式：ViewState受瀏覽器進程時間限制，無法完成超出瀏覽器進程的狀態保存。cookie可以不受時間限制但受存儲數據大小限制，僅能保存少量數據。session不受時間和大小限制，但受服務器資源限制，因為session無論是存儲在內存、還是以文件或數據庫方式存儲都會對服務器效率造成影響。但只有session才能滿足某些網站在狀態數據存儲的規模和安全性的要求。
1.基于頁面
基于頁面的方式可以在POST訪問時通過表單元素(input hidden)傳遞數據，可以通過在附加URL參數傳遞數據。基于頁面的方式強大的地方在于即使客戶端禁用了cookie或javascript，仍對服務器解析不構成影響。ASP.NET的ViewState只是基于頁面傳遞的一種應用。ASP.NET頁面將整個頁面視為一個包含了所有服務器控件的Web Form，默認的POST的URL只能是當前頁。ViewState原本是可以跨頁傳遞的，但由于ASP.NET頁面模型所限，只能起到POST當前頁面后維護頁面數據的作用。 在開始的ASP.NET事件模型中，你無法POST到其他頁面。Response.Redirect()還是Server.Transfer()都不可以，前者先POST回當前頁后采用頁面重定向，即使你Redirect到自身也還是重定向，后者POST到當前頁后再采用其他頁進行請求處理，雖然返回了其他頁的內容，但瀏覽器中的URL甚至都不會改變。到了ASP.NET 2.0才對客戶端提交表單前通過javascript強制POST到其他頁的方式實現了客戶端POST。而Web Form的action還是當前頁面。可能微軟也從未想過在其他頁面使用ViewState的需要，所以給該屬性設置了protected的保護。可是理論上，基于頁面的方式，無論是通過附加表單元素還是URL參數，都可以達到一致的效果。
不討論ASP.NET這種Web Form模型的弊利，我們如果需要考慮客戶端禁用了Cookie和JavaScript的情況（一般無需考慮），采用基于頁面的方式仍可以幫我們解決兩次請求之間共享數據的目的。 在工作經驗里，曾有一個PHP的多子站點的純信息展示類網站，由于唯一的用戶就是維護該網站的編輯，編輯需要在訪問網站時，對需要修改的地方直接修改，因此采用了ViewState的方式達到目的，根據是否登錄來決定是否加載啟用在線編輯的javascript文件，加載后每個區域雙擊即可彈出編輯框，編輯后即使提交通不過仍可繼續修改而不會丟失信息。
2.基于客戶端
cookie是客戶端技術，服務器采用動態網頁技術可以從客戶端讀取請求附加的cookie和向客戶端傳遞cookie，達到了在請求之間共享數據的目的。cookie的本身有著大小的限制，而即使沒有限制，攜帶過大的cookie對于請求的往返來說也是沉重的負擔。cookie是應用廣泛的維持狀態的方式。由于cookie使用HTTP請求頭和響應頭進行發送和接受，因此是一種服務器無關的技術。
3.基于服務器+客戶端
cookie可以設置過期時間，比基于頁面的技術更靈活，但只憑借客戶端的cookie進行驗證安全性存在隱患，而cookie的存儲大小又有限制，因此利用服務器端進行存儲擴充和驗證，這便是session技術。ASP.NET、PHP等都內置了對session的實現，一些大型的網站和框架也提供了自己的session的實現用于滿足各自的需求。大多數我們所見的網站，都使用了session技術。ASP.NET默認的session使用服務器內存存儲（通過Page.Session屬性使用，通過不同的會話提供程序，也可以用數據庫或其他的方式存儲），PHP默認的方式以服務器端文本存儲（同樣也支持內存或數據庫等自定義方式）。
如何使用？
其實ViewState、Cookie和Session在不同程度上解決不同請求之間的數據共享問題，這3種方式與服務器端采用的是PHP還是ASP.NET無關，這一點尤為重要。ViewState一般采用在頁面表單的源代碼中保存數據，其限制可想而知，不過用來完成類似防止表單出錯重填的功能還是沒問題的。cookie采取在客戶端以文本方式存放，雖然數據大小受限制且安全存在隱患，但存儲少量用戶信息還是足夠用的。session可以看做是對cookie的加強（不考慮基于url的session），在服務器端二次驗證，增強了安全性，利用服務器端資源，可以存儲大量數據。這樣看來，完全搞不懂為什么會出現對某個具體的網站有采用那種方式的糾結心態。
1.ViewState用于共享頁面狀態數據可以考慮，即使服務器端沒有直接支持，只要采用的是動態網頁技術，可以很容易實現。
2.Cookie一般可以滿足用戶ID、角色、個性化信息的簡單存儲。
3.Session對于電子商務類網站或需要通過一系列想到頁面完成某個任務的網站來說較為實用，因為單純使用Cookie這時從存儲數據的大小和安全性上來說，都很難勝任。
服務器端無論是采用ASP.NET還是PHP等，一般都會默認支持Session。但內置的Session可能會有各種各樣的問題，所以不要拿內置的Session來否定Session這種方式的必要性。
一個銷售虛擬游戲物品的網站，雖然同時在線人數不是很多，但由于其單個訂單包含的信息量，Cookie方式是根本無法滿足的。單位內部的查詢網站，采用Cookie存儲用戶ID和角色，完全夠用。
如果一個網站Cookie足可以滿足，那么搞不懂為什么要用Session。如果一個網站Session方式才能滿足需要，搞不懂怎么拋棄Session方式。曾就職于一個以虛擬物品網上交易作為主要業務的公司，其訪客無論是否注冊都可以將商品放入購物車中，很多wow的商品包含很多自定義參數可供客戶調節，無論注冊與否都可以生成預付訂單，對于未注冊用戶，即使關閉瀏覽器的之內，都可以再次訪問時查看加入到訂單中的商品，難以想象不使用session方式如何正常工作。如果說在cookie中只存儲必要的key，再訪問時從服務器中獲取，這本身就是session的定義。
沒有session實際使用的經歷，站在可以使用cookie就可以滿足需求的前提下去研究session方式在某個具體技術下的實現的缺點而直接否定session是沒有意義的，這如同使用扁平結構靜態頁的角度來抨擊樹形結構靜態頁網站的物理結構一樣。
小結
搞清某些技術的局限性，來分析是否滿足我們的實際需求，就不會把目光局限于技術本身的比較上。
所以，不要把簡單的問題搞復雜。實踐重要。本來就是為了在兩次請求之間傳遞狀態數據，無論請求頁面是否是同一頁面，只需要考慮低限度那種方式可滿足即可。如果不了解cookie的基礎知識，請自行baidu或google；如果看了概述就猜到我要說什么，那你在實際工作中有過應用。
關注我們要解決的問題，讓本來簡單的問題簡單。譬如Web服務器上都是靜態文件，URL包含了文件的路徑和文件名，甚至連URL參數都無法處理，只能采取客戶端javascript的偽過濾方式控制內容的顯示。后來的動態網頁技術可以在服務器端處理URL參數并根據請求動態生成內容，而后MVC方式出現，URL從直接對應路徑和文件名到映射Controller和Action。可是兩者的區別只在于看待問題的角度不同，沒有任何一種是另一種完全可以替代的，或者說，重點應該是能否恰到好處的解決問題。不要討論Web Form和ASP.NET MVC哪個好，在PHP早就可以任意匹配邏輯結構和物理結構，動態技術是否支持URL映射只是邏輯結構和物理結構映射的問題（幾年前寫一個只通過一個入動態頁入口，實現多個站點的方式，邏輯結構是分類+文章名，訪問時URL也是如此，但物理結構只有一個PHP文件作為入口，所有內容全部存儲在mysql數據庫中，因為需求要求可以通過數據庫備份整個網站，可以直接在幾十個網站中執行對內容的批量操作，讓我對邏輯結構和物理結構的映射一下子所得甚多），影響不到你對業務模型的抽象，對行為接口的提取和對業務流程的處理。
注1：簡單原則；注2：行動原則。
