注意 只有處理回發(fā)事件的控件參與此階段。 RaisePostBackEvent 方法
（如果已實(shí)現(xiàn) IPostBackEventHandler）
預(yù)呈現(xiàn) 在呈現(xiàn)輸出之前執(zhí)行任何更新?？梢员４嬖陬A(yù)呈現(xiàn)階段對控件狀態(tài)所做的更改，而在呈現(xiàn)階段所對的更改則會(huì)丟失。請參閱處理繼承的事件。 PreRender 事件
（OnPreRender 方法）
保存狀態(tài) 在此階段后，自動(dòng)將控件的 ViewState 屬性保持到字符串對象中。此字符串對象被發(fā)送到客戶端并作為隱藏變量發(fā)送回來。為了提高效率，控件可以重寫 SaveViewState 方法以修改 ViewState 屬性。請參閱維護(hù)控件中的狀態(tài)。 SaveViewState 方法
呈現(xiàn) 生成呈現(xiàn)給客戶端的輸出。請參閱呈現(xiàn) ASP.NET 服務(wù)器控件。 Render 方法
處置 執(zhí)行銷毀控件前的所有最終清理操作。在此階段必須釋放對昂貴資源的引用，如數(shù)據(jù)庫鏈接。請參閱 ASP.NET 服務(wù)器控件中的方法。
Dispose 方法
卸載 執(zhí)行銷毀控件前的所有最終清理操作。控件作者通常在 Dispose 中執(zhí)行清除，而不處理此事件。 UnLoad 事件（On UnLoad 方法）
　　從這個(gè)表里面我們可以清楚的看到一個(gè)Page從裝載到卸載之間調(diào)用的方法和觸發(fā)的時(shí)間，接下來我們就深入的對其進(jìn)行一些分析。
　　看了上面的表，細(xì)心的朋友可能要問了，既然OnInit是頁面生命周期的開始，而我們在上一講中談到控件在子類中被創(chuàng)建，那么在這里實(shí)際上在InitializeComponent方法中我們已經(jīng)可以使用父類中聲名的字段了，那么就意味著子類的初始化更在這之前？
　　在第三個(gè)標(biāo)題中我們講到了頁面類的ProcessRequest才是真正意義上的頁面聲明周期的開始，這個(gè)方法是由HttpApplication調(diào)用的（其中調(diào)用的方式比較復(fù)雜，有機(jī)會(huì)單獨(dú)撰文來講解），一個(gè)Page對請求的處理就是從這個(gè)方法開始，通過反編譯.Net類庫來查看源代碼，我們發(fā)現(xiàn)在System.Web.WebControls.Page的基類：System.Web.WebControls.TemplateControl（它是頁面和用戶控件的基類）中定義了一個(gè)“FrameworkInitialize”虛擬方法，然后在Page的ProcessRequest中最先調(diào)用了這個(gè)方法，在生成器生成的ASPX的源代碼中我們發(fā)現(xiàn)了這個(gè)方法的蹤影，所有的控件都在這個(gè)方法中被初始化，頁面的控件樹就在這個(gè)時(shí)候產(chǎn)生。
　　接下來的事情就簡單了，我們來逐步分析頁面生命周期的每一項(xiàng)：
　　1、初始化
　　初始化對應(yīng)Page的Init事件和OnInit方法。
　　如果要重寫，MSDN推薦的方式是重載OnInti方法，而不是增加一個(gè)Init事件的代理，這兩者是有差別的，前者可以控制調(diào)用父類OnInit方法的順序，而后者只能在父類的OnInit后執(zhí)行（實(shí)際上是在OnInit里面被調(diào)用的）。
　　2、 加載視圖狀態(tài)
　　這是個(gè)比較重要的方法，我們知道，對于每次請求，實(shí)際上是由不同的頁面類實(shí)例來處理的，為了保證兩次請求間的狀態(tài)，ASP.Net使用了ViewState。
　　LoadViewState方法就是從ViewState中獲取上一次的狀態(tài)，并依照頁面的控件樹的結(jié)構(gòu)，用遞歸來遍歷整個(gè)樹，將對應(yīng)的狀態(tài)恢復(fù)到每一個(gè)控件上。
　　3、 處理回發(fā)數(shù)據(jù)
　　這個(gè)方法是用來檢查客戶端發(fā)回的控件數(shù)據(jù)的狀態(tài)是否發(fā)生了改變。方法的原型：
public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)
　　postDataKey是標(biāo)識控件的關(guān)鍵字（也就是postCollection中的Key），postCollection是包含回發(fā)數(shù)據(jù)的集合，我們可以重寫這個(gè)方法，然后檢查回發(fā)的數(shù)據(jù)是否發(fā)生了變化，如果是則返回一個(gè)True，“如果控件狀態(tài)因回發(fā)而更改，則 LoadPostData 返回 true；否則返回 false。頁框架跟蹤所有返回 true 的控件并在這些控件上調(diào)用 RaisePostDataChangedEvent?！保ㄕ訫SDN）
　　這個(gè)方法是System.Web.WebControls.Control中定義的，也是所有需要處理事件的自定義控件需要處理的方法，對于我們今天討論的Page來說，可以不用管它。
　　4、 加載
　　加載對應(yīng)Load事件和OnLoad方法，對于這個(gè)事件，相信大多數(shù)朋友都會(huì)比較熟悉，用VS.Net生成的頁面中的Page_Load方法就是響應(yīng)Load事件的方法，對于每一次請求，Load事件都會(huì)觸發(fā)，Page_Load方法也就會(huì)執(zhí)行，相信這也是大多數(shù)人了解ASP.Net的第一步。
　　Page_Load方法響應(yīng)了Load事件，這個(gè)事件是在System.Web.WebControl.Control類中定義的（這個(gè)類是Page和所有服務(wù)器控件的祖宗），并且在OnLoad方法中被觸發(fā)。
　　很多人可能碰到過這樣的事情，寫了一個(gè)PageBase類，然后在Page_Load中來驗(yàn)證用戶信息，結(jié)果發(fā)現(xiàn)不管驗(yàn)證是否成功，子類頁面的Page_Load總是會(huì)先執(zhí)行，這個(gè)時(shí)候很可能留下一些安全性的隱患，用戶可能在沒有得到驗(yàn)證的情況下就執(zhí)行了子類中的Page_Load方法。
　　出現(xiàn)這個(gè)問題的原因很簡單，因?yàn)镻age_Load方法是在OnInit中被添加到Load事件中的，而子類的OnInit方法中是先添加了Load事件，然后再調(diào)用base.OnInit，這樣就造成了子類的Page_Load被先添加，那么先執(zhí)行了。
　　要解決這個(gè)問題也很簡單，有兩種方法：
　　1） 在PageBase中重載OnLoad方法，然后在OnLoad中驗(yàn)證用戶，然后調(diào)用base.OnLoad，因?yàn)長oad事件是在OnLoad中觸發(fā)，這樣我們就可以保證在觸發(fā)Load事件之前驗(yàn)證用戶。
　　2） 在子類的OnInit方法中先調(diào)用base.OnInit，這樣來保證父類先執(zhí)行Page_Load
　　5、 發(fā)送回發(fā)更改通知
　　這個(gè)方法對應(yīng)第3步的處理回發(fā)數(shù)據(jù)，如果處理回發(fā)數(shù)據(jù)返回True，頁面框架就會(huì)調(diào)用此方法來觸發(fā)數(shù)據(jù)更改的事件，所以自定義控件的回發(fā)數(shù)據(jù)更改事件需要在此方法中觸發(fā)。
　　同樣這個(gè)方法對于Page來說，沒有太大的用處，當(dāng)然你也可以在Page的基礎(chǔ)上自己定義數(shù)據(jù)更改的事件，這當(dāng)然也是可以的。
　　6、 處理回發(fā)事件
　　這個(gè)方法是大多數(shù)服務(wù)器控件事件引發(fā)的地方，當(dāng)請求中包含控件事件觸發(fā)的信息時(shí)（服務(wù)器控件的事件是另一個(gè)論題，我會(huì)在不久將來另外撰文討論），頁面控件會(huì)調(diào)用相應(yīng)控件的RaisePostBackEvent方法來引發(fā)服務(wù)器端的事件。
　　這里又引出一個(gè)常見的問題：
　　經(jīng)常有網(wǎng)友問，為什么修改提交后的數(shù)據(jù)并沒有更改
　　多數(shù)的情況都是他們沒有理解服務(wù)器事件的觸發(fā)流程，我們可以看出，觸發(fā)服務(wù)器事件是在Page的Load之后，也就是說頁面會(huì)先執(zhí)行Page_Load，然后才會(huì)執(zhí)行按鈕（這里以按鈕為例）的點(diǎn)擊事件，很多朋友都是在Page_Load中綁定數(shù)據(jù)，然后在按鈕事件中處理更改，這樣做有一個(gè)毛病，Page_Load永遠(yuǎn)都是在按鈕事件之前執(zhí)行，那么意味著數(shù)據(jù)還沒來得及更改，Page_Load中的數(shù)據(jù)綁定的代碼就先執(zhí)行了，原有的數(shù)據(jù)又賦給了控件，那么執(zhí)行按鈕事件的時(shí)候，實(shí)際上獲得的是原有的數(shù)據(jù)，那么更新當(dāng)然就沒有效果了。
　　更改這個(gè)問題也非常簡單，比較合理的做法是把數(shù)據(jù)綁定的代碼寫成一個(gè)方法，我們假設(shè)為BindData：

　　7、預(yù)呈現(xiàn)
　　最終請求的處理都會(huì)轉(zhuǎn)變?yōu)榘l(fā)回服務(wù)器的響應(yīng)，預(yù)呈現(xiàn)這個(gè)階段就是執(zhí)行在最終呈現(xiàn)之前所作的狀態(tài)的更改，因?yàn)樵诔尸F(xiàn)一個(gè)控件之前，我們必須根據(jù)它的屬性來產(chǎn)生Html，比如Style屬性，這是最典型的例子，在預(yù)呈現(xiàn)之前，我們可以更改一個(gè)控件的Style，當(dāng)執(zhí)行預(yù)呈現(xiàn)的時(shí)候，我們就可以把Style保存下來，作為呈現(xiàn)階段顯示Html的樣式信息。
　　8、保存狀態(tài)
　　這個(gè)階段是針對加載狀態(tài)的，我們多次提到，請求之間是不同的實(shí)例在處理，所以我們需要把本次的頁面和控件的狀態(tài)保存起來，這個(gè)階段就是把狀態(tài)寫入ViewState的階段。
　　9、呈現(xiàn)
　　到這里，實(shí)際上頁面對請求的處理基本就告一段落了，在Render方法中，會(huì)遞歸整個(gè)頁面的控件樹，依次調(diào)用Render方法，把對應(yīng)的Html代碼寫入最終響應(yīng)的流中。
　　10、處置
　　實(shí)際上就是Dispose方法，在這個(gè)階段會(huì)釋放占用的資源，例如數(shù)據(jù)庫連接。
　　11、卸載
　　最后，頁面會(huì)執(zhí)行OnUnLoad方法觸發(fā)UnLoad事件，處理在頁面對象被銷毀之前的最后處理，實(shí)際上ASP.Net提供這個(gè)事件只是設(shè)計(jì)上的考慮，通常資源的釋放都會(huì)在Dispose方法中完成，所以這個(gè)方法也變成雞肋了。
　　我們簡單的介紹了頁面的生存周期，對于服務(wù)器端事件的處理做了不太深入的講解，今天主要是想大家了解頁面執(zhí)行的周期，對于服務(wù)器控件的事件和生存期我會(huì)在后續(xù)在寫一些文章來探討。
　　這些內(nèi)容是我在學(xué)習(xí)ASP.Net的時(shí)候?qū)age研究的一些心得，具體的細(xì)節(jié)沒有很詳細(xì)的探討，更多的內(nèi)容請大家參考MSDN，但是我舉了一些初學(xué)者常犯的錯(cuò)誤和出現(xiàn)錯(cuò)誤的原因，希望可以給大家?guī)韱l(fā)。

最新評論