在一個基于ASP.NET的Web應(yīng)用程序中，我們通常使用SessionState保存基于某個客戶端的狀態(tài)信息。但是這種單純使用SessionState的編程方式具有很多局限，比如Session Item的Key值沖突，比如沒有一個有效的SessionState清除機(jī)制會為Web Server帶來內(nèi)存壓力。為了實(shí)現(xiàn)對客戶端狀態(tài)的有效管理，并提高應(yīng)用開發(fā)效率，在很多年前我們的開發(fā)框架體系中就具有相應(yīng)的一個叫做State的編程框架。最近我開始對其進(jìn)行升級和重新設(shè)計，將實(shí)現(xiàn)原理和概要設(shè)計方面的東西寫出來與大家共享，希望對各位有些啟發(fā)。同時希望借此得到你們一些好的建議和意見，以便能夠充實(shí)我們的框架。于此同時，我寫了一個簡單的模擬程序?qū)崿F(xiàn)了該設(shè)計思想，有興趣的話可以通過這里下載該模擬程序。

一、單純基于SessionState編程的局限性

　　SessionState對于ASP.NET的開發(fā)者在熟悉不過了，我們可以通過它來存儲一些基于客戶端的狀態(tài)信息。從編程角度來說，SesssionState是依附和當(dāng)前HttpContext的一個用于類似于字典的數(shù)據(jù)容器，我們通過鍵值對的方式進(jìn)行Session Item的設(shè)置和獲取。但是這種單純地基于字典索引的編程方式，具有諸多局限：

　　首先，這種弱類型的編程方式不便于快速開發(fā)需求。放入SessionState的值是一個System.Object類型的對象，在獲取的使用我們需要進(jìn)行手工轉(zhuǎn)型；而Session Item的Key是手工指定的字符串，如果沒有對Key值進(jìn)行有效的分配，在進(jìn)行設(shè)置的時候很容易造成一個Key值得沖突，從而導(dǎo)致整個狀態(tài)的混亂；在獲取某個Session Item的時候，你指定的Key值可能和預(yù)先指定的不符。

　　其次，統(tǒng)一的SessionState的清除機(jī)制的缺乏導(dǎo)致服務(wù)端內(nèi)存壓力。在默認(rèn)的情況下（采用InProc會話模式），SessionState存儲于服務(wù)端內(nèi)存，如果過多、過大的Session Item常駐內(nèi)存，勢必會為服務(wù)端帶來內(nèi)存壓力。實(shí)際上，基于客戶端的所有的Session Item并不是在整個Session存續(xù)期間都是必須的，很多Session Item僅僅是在某幾個少數(shù)的Web頁面中使用。但是我們不能通過程序手工地將其從SessionState中刪除，因?yàn)槲覀儾荒艽_定該Session Item在那一刻不再需要，因?yàn)檫@往往取決于UI交互的行為。如果太多的低頻率使用的Session Item存在，并且它們還不小，服務(wù)端內(nèi)存過多地被占用必要導(dǎo)致性能的下降。

　　最后，如果你采用State Server或者SQL Server會話管理模式，還會造成更多的性能問題。這樣的性能損失包括：Session Item的序列化和反序列化、序列化后的Session Item在Web Server和State Server或者SQL Server的網(wǎng)絡(luò)傳輸、針對State Server或者SQL Server的數(shù)據(jù)存取（保存和提取）等。

　　實(shí)際上，我們的State框架還是建立在SessionState基礎(chǔ)之上，但是它能夠很好的解決上述的三大難題：

• 通過配置為所有使用到的狀態(tài)項（狀態(tài)屬性名稱、數(shù)據(jù)類型等）提供結(jié)構(gòu)化的定義，并通過基于該結(jié)構(gòu)化配置提供的代碼生成使強(qiáng)類型編程成為可能。這比較類似于ASP.NET中Profile的配置和強(qiáng)類型編程的方式；
• 提供狀態(tài)的后備存儲（Backing Storing）機(jī)制將低頻率使用的大對象從SessionState中移到相應(yīng)的后備存儲（比如文件、數(shù)據(jù)庫）中，從而緩解服務(wù)端內(nèi)存壓力；
• 提供靈活的后備策略定義方式以實(shí)現(xiàn)基于具體運(yùn)行環(huán)境的最優(yōu)配置。后備策略主要包括兩方面的內(nèi)容，其一是怎樣的狀態(tài)項需要被后備存儲，其二采用怎樣的方式進(jìn)行后備存儲。確定后備存儲狀態(tài)項的因素包括：自最近一次被訪問以來的超時時限（通過使用頻率判斷狀態(tài)項再次被使用的可能性）；需要被后備存儲對象必須具有的最小字節(jié)數(shù)（后備存儲小對象毫無意義） ；以及狀態(tài)項的作用域（很多狀態(tài)項的作用范圍僅僅限于某一個相關(guān)的Web頁面，或者基于某個基地址）等。而具體采用的后備存儲方式?jīng)Q定于配置的"后備存儲器"，比如在我提供的例子中采用的是基于文件的存儲方式，你可以編寫基于數(shù)據(jù)庫的后備存儲器。

二、通過狀態(tài)后備存儲機(jī)制解決Web Server內(nèi)存的壓力

　　狀態(tài)的后備機(jī)制是整個狀態(tài)編程框架的核心。通過對所有狀態(tài)項的掃描，標(biāo)記出所有需要進(jìn)行后備存儲的狀態(tài)項。然后將它們進(jìn)行序列化，并借助于指定的后備存儲器將它們存儲到相應(yīng)的物理存儲介質(zhì)。最后，相應(yīng)的狀態(tài)會從SessionState中刪除，從而緩解了Web Server的內(nèi)存壓力。除了將序列化的狀態(tài)對象進(jìn)行后備存儲之前，后備存儲器還負(fù)責(zé)從相應(yīng)的存儲介質(zhì)中提取狀態(tài)數(shù)據(jù)。

　　簡單起見，我們并沒有在后臺運(yùn)行一個實(shí)施后備檢測操作的引擎，而是直接通過事件注冊的方式讓每一個請求自動去觸發(fā)基于本會話的后備存儲，我們注冊的事件是HttpApplication的PostRequestHandlerExecute。出于性能的考慮，當(dāng)事件PostRequestHandlerExecute被觸發(fā)的時候，并不是總是立即執(zhí)行后備狀態(tài)項的檢查。而是設(shè)置一個相鄰兩次后備檢查的間隔，只有超出這個間隔的情況下，才會進(jìn)行真正地區(qū)檢查那些狀態(tài)向需要進(jìn)行后備存儲了。狀態(tài)項的后備存儲緊接著在后備對象的檢查之后進(jìn)行。

　　我們通過一個具體的例子來進(jìn)一步說明后備存儲的過程。如左圖（點(diǎn)擊看大圖）所示，在Web Server的IIS進(jìn)程中的SessionState中維持著三個狀態(tài)項：Foo、Bar、Baz。當(dāng)Web Server接收并執(zhí)行來自瀏覽器的HTTP請求后，PostRequestHandlerExecute事件的處罰激活了我們的后備檢查管理器，它發(fā)現(xiàn)狀態(tài)項Baz最近一次被訪問的時間到當(dāng)前時間的間隔已經(jīng)超出了設(shè)置的超時時限，并且計算出該對象的總字節(jié)數(shù)超過了設(shè)定的下限，就會將該對象標(biāo)記為后備存儲對象。在這種情況下，狀態(tài)項Baz的值，同它的Key一并進(jìn)行序列化并進(jìn)行后備存儲。最后將該Baz從SessionState中移除。

　　如果該Web應(yīng)用使用Web Farm部署方式，并采用了Sate Server或者SQL Server的會話模式，在同步到Sate Server或者SQL Server的時候，由于SessionState中缺少了Baz這個大對象，也會因?yàn)樯倭藢λ蛄谢?網(wǎng)絡(luò)傳輸和數(shù)據(jù)存取使性能得到相應(yīng)的提升。

三、后備存儲狀態(tài)項的"復(fù)蘇"

　　被后備存儲的狀態(tài)項已經(jīng)不再存儲于SessionState中，但是并不意味著它已經(jīng)是所謂的垃圾對象，它們依然可以被再次訪問。在這種情況下，我們會通過我們指定的后備存儲器將相應(yīng)的狀態(tài)值以字節(jié)數(shù)組的形式從存儲介質(zhì)中提取出來，進(jìn)行反序列化后再次放到SessionState中，我個人將這種機(jī)制成為"后備對象的復(fù)蘇"。

　　在對后備對象的復(fù)蘇機(jī)制進(jìn)行進(jìn)一步講解之前，我們需要了解一個前提：框架始終維護(hù)著每一個狀態(tài)項運(yùn)行時信息，這些信息包括：狀態(tài)項最后一次被訪問的時間、狀態(tài)項的使用范圍、狀態(tài)項當(dāng)前的存儲位置（SessionState或者BackingStore）、以及相關(guān)的后備策略信息等。這個列表放在SessionState中。

　　右面所示的序列圖（點(diǎn)擊看大圖）反映了當(dāng)我們的程序獲取某個狀態(tài)項時，狀態(tài)后備機(jī)制采用的處理流程：當(dāng)接收到一個來自對某個狀態(tài)項的請求時，根據(jù)Key值獲取該狀態(tài)項當(dāng)前的運(yùn)行時信息。如果運(yùn)行時信息反映它還存在于SessionState中（Location=Session），則直接從SessionState中返回，并更新它的運(yùn)行時信息（最后一次被訪問時間）。

　　如果該狀態(tài)項已經(jīng)進(jìn)行了背后存儲（Location=BackingStore），則借助相應(yīng)的后備存儲器從存儲介質(zhì)中對應(yīng)的值以字節(jié)數(shù)組的形式提取出來。在完成反系列化后再次保存到SessionState中，并更新相應(yīng)運(yùn)行時信息（最后一次訪問時間和當(dāng)前位置：BackingStore-〉Session）。最后返回反序列化后的具體狀態(tài)對象。

四、狀態(tài)項后備策略的定義

　　判斷一個存在于SessionState中的狀態(tài)項是否應(yīng)該被后備存儲取決于以下三個方面，當(dāng)同時滿足條件1和2，或者2和3的狀態(tài)項會被后備存儲。

• 針對該狀態(tài)項的最近一次訪問的事件到當(dāng)前時間的間隔超過了設(shè)定的超時時限；
• 狀態(tài)項的總的字節(jié)數(shù)超過了設(shè)定的需要進(jìn)行后備存儲的下限；
• 當(dāng)前的請求的URL是否超出了設(shè)定的狀態(tài)作用的范圍。
   

　　但是我們的狀態(tài)后備策略并沒有直接應(yīng)用于單個的狀態(tài)項，而是應(yīng)用于一個較大的粒度：狀態(tài)組——若干相關(guān)狀態(tài)項的組合。狀態(tài)組的結(jié)構(gòu)和應(yīng)用在它上面的后備策略通過配置進(jìn)行定義，下面的XML體現(xiàn)的配置大體上的結(jié)構(gòu)。

<?xml version="1.0" encoding="utf-8" ?>
<states>
<properties>
<property name="UserName" type="System.String"/>
<property name="Position" type="System.String"/>
</properties>
<group name=&quot;Profile" inactiveTimeout=

"00:10:00" minimunTotalBytes="1024" >
<property name="Age" type="System.Int32"/>
<property name="Address" type="System.String"/>
</group>
<group name="Product" inactiveTimeout="00:10:00"
minimunTotalBytes="1024" scope="Page1, Page2,Page3" >
<property name="ProductId" type="System.String"/>
<property name="UnitPrice" type="System.Decimal"/>
</group>
</states>

　　在上面的XML片段中，我們定義兩個全局的狀態(tài)項（UserName和Position）和兩個狀態(tài)組（Profile和Product）。兩個狀態(tài)組中又包含各自的狀態(tài)項，以及對應(yīng)的后備策略。inactiveTimeout、minimumTotlaBytes和scope分別表示超時時限、序列化后的最下值和使用的范圍。

五、通過代碼生成機(jī)制幫助你以強(qiáng)類型的方式操作狀態(tài)

　　既然所有的狀態(tài)和數(shù)據(jù)類型（即可以是系統(tǒng)預(yù)定義類型，也可以是自定義類型）都能通過XML的形式表示出來，那么我們就能通過代碼生成機(jī)制將它們通過代碼的形式反映出來。你可以采用CodeDOM+Cutom Tool的方式[可以參考我的文章《從數(shù)據(jù)到代碼》（上篇、下篇）]，或者是直接使用T4模板[可以參考我的文章《創(chuàng)建代碼生成器可以很簡單：如何通過T4模板生成代碼？》（上篇、下篇）]。比如說，你可以生成一個繼承自Page的類型，比如PageBase，添加如下一個State的屬性。（下面的代碼僅僅代碼大體的結(jié)構(gòu)，并省略的具體的實(shí)現(xiàn)）

public class PageBase : Page
{
public ExtendedRootStateNode State { get; }
}
public class ExtendedRootStateNode : RootStateNode
{
public string UserName { get; set; }
public string Position { get; set; }
public ProfileGroupStateNode Profile { get; private set; }
public ProductGroupStateNode Product { get; private set; }
}
public class ProfileGroupStateNode : GroupStateNode
{
public int Age { get; set; }
public Gender Gender { get; set; }
public string Address { get; set; }
}
public class ProductGroupStateNode : GroupStateNode
{
public string ProductId { get; set; }
public string ProductName { get; set; }
}

如果讓你的所有Web頁面都繼承自這個PageBase，你可以通過強(qiáng)類型的方式獲取或者設(shè)置每個狀態(tài)項了。