淺談ASP.NET頁面生命周期
ASP.NET的優(yōu)點(diǎn)我說過很多次了，也就是各個控件獨(dú)立負(fù)責(zé)自己內(nèi)部的邏輯，這是一個好事情，因為它解決了原本ASP處理邏輯耦合度高的問題。然而這是需要代價的，那就是引入ASP.NET頁面生命周期，隨著控件的多層嵌套，應(yīng)用的復(fù)雜度增加，我們再次陷入泥潭！
其實這個文章題目我兩個月前就寫下了，可是一直沒想寫完它，直到今天我在這個泥潭中泡了幾個小時，于是決定先從泥潭中跳出來把文章寫完，再跳進(jìn)去繼續(xù)解決問題。問題是這樣的：
1. 使用MS AJAX 1.0 Beta2 + 2.0 CTP新建一個項目，同時在Bin中放上Beta2的AjaxControlToolkit.dll。
2. 扔上一個Accordion，放置幾個AccordionPane，設(shè)置一下CssClass。
3. 在Page_Load中使用Page.LoadControl加載一個UserControl，然后添加到頁面上。
4. 接著發(fā)現(xiàn)UserControl內(nèi)的控件無法正常觸發(fā)事件，陷入泥潭中……
首先要說明，如果僅僅做第3步那個UserControl肯定正常運(yùn)作，那意味著問題出在ScriptManager或Accordion中出現(xiàn)了問題。
想知道到底是什么出問題了嗎？先聽我說說這個ASP.NET頁面生命周期的問題吧。
由于ASP.NET頁面生命周期按階段劃分，任務(wù)在不同階段按部就班完成，所以我們的每一個操作都是階段相關(guān)的，有些操作僅能在特定的階段操作，有些操作在不同階段執(zhí)行會導(dǎo)致不同的結(jié)果。當(dāng)然，MS希望盡量消除這些階段間的差異，例如讓一個操作在盡可能多的階段中都能執(zhí)行，并且盡可能減少在不同階段中操作引發(fā)的不同結(jié)果。然而這不可能完全做到，例如我們都知道ViewState讀寫限制為僅能在某些階段進(jìn)行，于是依賴于ViewState的控件屬性也就因此受到同樣的限制。
控件屬性讀寫受階段限制，這很好接受，對吧？因為這僅僅是一層依賴關(guān)系。順著依賴關(guān)系推廣出去，情況會變得越來越復(fù)雜，限制的原因埋藏得越來越底層，接著我們發(fā)現(xiàn)復(fù)雜性這一問題在ASP.NET這種結(jié)構(gòu)良好的體系中出現(xiàn)了，而消滅這種復(fù)雜性的銀彈還沒被發(fā)明。
作為控件或組件的開發(fā)人員，我們當(dāng)然有義務(wù)消除階段差異，讓下游的開發(fā)人員面對更低的復(fù)雜性，而且我們也確實盡力去做了。控件的每一層封裝，都包含著這種努力，并向上承諾盡可能低的階段差異。然而為了讓控件看起來簡單易用，我們不可能將這些差異完整地記錄在文檔之中，我們嘗試去隱瞞細(xì)節(jié)，控件被層層封裝時我們都這樣做。底層文檔沒告訴我的差異，我當(dāng)然也沒必要寫到這一層的文檔上去；底層文檔提及了的差異，我盡力彌補(bǔ)了，即使彌補(bǔ)得不太好，也不寫到這一層的文檔上去。于是文檔就好像神話傳說一樣隨著世代相傳而改變，最終沒有人知道這個控件依賴于某些底層的階段差異。
做過控件開發(fā)的人都知道，有時候我們必須根據(jù)實際情況采用不同的方式構(gòu)建看起來一樣的控件。例如最簡單的數(shù)據(jù)控件都會存在是否PostBack的構(gòu)建差異，如果是非 PostBack，則需要在DataBind時構(gòu)建并將數(shù)據(jù)保存到ViewState，如果是PostBack則根據(jù)ViewState直接構(gòu)建，如果 PostBack后又遇到了DataBind則需要清除原來的構(gòu)建并重新根據(jù)新數(shù)據(jù)構(gòu)建。再復(fù)雜一些的控件，還會分步驟構(gòu)建，默認(rèn)情況下為了消除使用方的階段差異，部分構(gòu)建步驟會盡可能靠前到Init時執(zhí)行，而另外一部分構(gòu)建步驟則盡可能推遲到PreRender時執(zhí)行，中間部分則盡可能減少自己的變化以便使用方操作。然而事情不會那么簡單，使用方的某些操作（通常是訪問某個屬性）如果依賴于某個構(gòu)建步驟的完成，因此一旦這些操作出現(xiàn)，原本在 PreRender才執(zhí)行的特定構(gòu)建步驟就要提前執(zhí)行，當(dāng)這樣的操作在不同階段進(jìn)行多幾次，構(gòu)建步驟就已經(jīng)散落在ASP.NET頁面生命周期的各階段。
構(gòu)建步驟可能散落于ASP.NET頁面生命周期的各階段對于控件設(shè)計師來說是一個嚴(yán)峻的問題，這意味著他要保證任何一個構(gòu)建步驟在任何一個階段執(zhí)行都是無差異的，當(dāng)然這不可能做到，于是又要引入別的機(jī)制來減少這種差異，復(fù)雜性就此產(chǎn)生了，接下來隨著復(fù)雜性的增加控件設(shè)計師越來越無法確保較低的階段差異程度，這就到控件使用者遭殃了，如果控件使用者又再把控件封裝，并且依然企圖降低階段差異程度，那么災(zāi)難也就發(fā)生了……
我花了幾個小時在泥潭中泡了幾個小時，邊泡邊寫這篇文章，問題當(dāng)然已經(jīng)有結(jié)果了。
如果Accordion設(shè)置了HeaderCssClass或者ContentCssClass，那就會出問題，但如果為AccordionPane都加上以上兩個屬性，又不會有問題了。這樣的情況當(dāng)然通過用Reflector查看這兩個類的代碼來解決，結(jié)果發(fā)現(xiàn)Accordion會檢測每一個 AccordionPane是否有設(shè)置這兩個屬性，如果沒有就把AccordionPane的設(shè)置為和自己的一樣。在AccordionPane被設(shè)置時，會調(diào)用this.EnsureChildControls()，這是一個會導(dǎo)致構(gòu)建步驟提前執(zhí)行的方法，于是控件構(gòu)建的順序就改變了，不僅僅 Accordion內(nèi)部的順序改變了，整個Page的都改變了。由于控件的ID是按順序自動分配的，包括我那個UserControl，構(gòu)建順序的改變意味著ID的改變，也就相當(dāng)于整個控件樹都改變了，事件當(dāng)然不能正常觸發(fā)。
***的解決方案當(dāng)然是為我那個UserControl指定ID。我花了那么多個小時才發(fā)現(xiàn)自己做了件蠢事，一早打開Trace來看控件樹就應(yīng)該能發(fā)覺UniqueID的變化。
雖然這個問題看起來不是一個太好的例子，因為一打開Trace就應(yīng)該能找到問題的來源，但實際上它卻正好揭示了ASP.NET框架內(nèi)部的“蝴蝶效應(yīng)(Butterfly Effect)”——隨著復(fù)雜度的增加，任何一個細(xì)微的改變都會導(dǎo)致全局上的巨大變化。在設(shè)計ASP.NET的時候，MS可能也在想著解耦，在簡單的情況下這東西確實也解耦，然而在復(fù)雜的情況下卻正好背道而馳，這真的是很諷刺。
【編輯推薦】
