ASP.NET Web Page應用深入探討

2024-07-10 12:55:29

字體：大中小

來源：轉載

供稿：網友

一、服務器腳本基礎介紹

　　首先，我們先復習一下web服務器頁面的基本執行方式：

　　1、客戶端通過在瀏覽器的地址欄敲入地址來發送請求到服務器端

　　2、服務器接收到請求之后，發給相應的服務器端頁面（也就是腳本）來執行，腳本產生客戶端的響應，發送回客戶端

　　3、客戶端瀏覽器接收到服務器傳回的響應，對html進行解析，將圖形化的網頁呈現在用戶面前

　　對于服務器和客戶端的交互，通常通過下面幾種主要方式：

　　1、form：這是最主要的方式，標準化的控件來獲取用戶的輸入，form的提交將數據發送給服務器端處理

　　2、querystring：通過在url后面帶參數達到將參數傳送給服務器，這種方式其實跟get方式的form是一樣的

　　3、cookies：這是一種比較特殊的方式，通常用于用戶身份的確認

　　二、asp.net簡介

　　傳統的服務器腳本語言，如asp、jsp等，編寫服務器腳本的方式大同小異，都是在html中嵌入解釋或編譯執行的代碼，由服務器平臺執行這些代碼來生成html；對于這類似的腳本，頁面的生存周期實際上很簡單，就是從開頭至末尾，執行完所有的代碼，當然用java編寫的servlet可以編寫更復雜的代碼，但是從結構上看，和jsp沒什么區別。

　　asp.net的出現，打破了這種傳統；asp.net采用了codebehind技術和服務器端控件，加入了服務器端的事件的概念，改變了腳本語言編寫的模式，更加貼近window編程，使web編程更加簡單、直觀；但是我們要看到，asp.net本身并沒有改變web編程的基本模式，只是封裝了一些細節、提供了一些易用的功能，使代碼更容易編寫和維護；從某種程度上來說，將服務器端執行的方式復雜化了，這就是我們今天要討論的主體：asp.net web page的生存周期。

　　三、asp.net請求處理模式

　　我們說，asp.net的web page并沒有脫離web編程的模式，所以它仍然是以請求-＞接收請求-＞處理請求-＞發送響應這樣的模式在工作，每一次與客戶端的交互都會引發一次新的請求，所以一個web page的生命周期是以一次請求為基礎的。

　　當iis收到客戶端的請求的時候，會將請求交給aspnet_wp這個進程來處理，這個進程會查看請求的應用程序域是否存在，如果不存在則會創建一個，然后會創建一個http運行時（httpruntime）來處理請求，這個運行時“為當前應用程序提供一組 asp.net 運行時服務”（摘自msdn）。

　　httpruntime在處理請求的時候，會維護一系列的應用程序實例，也就是應用程序的global類（global.asax）的實例，這些實例在沒有請求的時候，會存放在一個應用程序池中（實際上應用程序池由另一個類來維護，httpruntime只是簡單的調用），每接收到一個請求，httpruntime都會獲取一個閑置的實例來處理請求，這個實例在請求結束前不會處理其他的請求，處理完畢之后，它又會回到池中，“一個實例在其生存期內被用于處理多個請求，但它一次只能處理一個請求。”（摘自msdn）

　　當應用程序實例處理請求的時候，它會創建請求頁面類的實例，執行它的processrequest方法來處理請求，這個方法也就是web page生命周期的開始。

　　四、aspx頁面與codebehind

　　在深入了解頁面的生命周期之前，我們先來探討一些aspx與codebehind之間的關系。

＜%@ page language="c#" codebehind="webform.aspx.cs" inherits="mynamespace.webform" %＞

　　相信使用過codebehind技術的朋友，對aspx頂部的這句話應該是非常熟悉了，我們來一項一項的分析它：

　　page language="c#" 這個就不用多說了吧

　　codebehind="webform.aspx.cs" 這一句表示綁定的代碼文件

　　inherits="mynamespace.webform" 這句非常重要，它表示頁面繼承的類名稱，也就是codebehind的代碼文件中的類，這個類必須從system.web.webcontrols.page派生

　　從上面我們可以分析出，實際上codebehind中的類就是頁面（aspx）的基類，到這里，可能有些朋友要問了，在編寫aspx的時候，完全是按照asp的方式，在html中嵌入代碼或者嵌入服務器控件，沒有看到所謂“類”的影子啊？

　　這個問題實際上并不復雜，各位使用asp.net編程的朋友可以到你們的系統盤：/windows/microsoft.net/framework/＜版本號＞/temporary asp.net files這個目錄下，這個下面就放了所有本機上存在的asp.net應用程序的臨時文件，子目錄的名稱就是應用程序的名稱，然后再下去兩層（為了保證唯一，asp.net自動產生了兩層子目錄，并且子目錄名稱是隨機的），然后我們會發現有很多類似：“yfy1gjhc.dll”、“xeunj5u3.dll”這樣的鏈接庫以及“komee-bp.0.cs”、“9falckav.0.cs”這樣的源文件，實際上這就是aspx被asp.net動態編譯后的結果，打開這些源文件我們可以發現：

public class webform_aspx : mynamespace.webform, system.web.sessionstate.irequiressessionstate
　　這就印證了我們前面的說法，aspx是代碼綁定類的子類，它的名稱是aspx文件名加上“_aspx”后綴，通過研究這些代碼我們可以發現，實際上所有aspx中定義的服務器控件都是在這些代碼中生成的，然后動態產生這些代碼的時候，把原來在aspx中嵌入的代碼寫在了相應的位置。

　　當某個頁面第一次被訪問的時候，http運行時就會使用一個代碼生成器去解析aspx文件并生成源代碼并編譯，然后以后的訪問就直接調用編譯后的dll，這也是為什么aspx第一次訪問的時候非常慢的原因。

　　解釋了這個問題，我們再來看另一個問題。我們在使用代碼綁定的時候，在設計頁面拖一個控件，然后切換到代碼視圖，就可以直接在page_load中使用這個控件了，既然控件是在子類中產生的，那為什么在父類中可以直接使用呢？

　　實際上我們可以發現，每當用vs.net拖一個控件到頁面上，代碼綁定文件中總是會類似這樣的添加一個聲明：

protected system.web.webcontrols.button button1;
　　我們可以發現這個字段被聲明成protected，而且名字與aspx中控件的id一致，仔細想一想，這個問題就迎刃而解了。我們前面提到aspx的源代碼是被生成器動態生成和編譯的，生成器會產生動態生成每一個服務器控件的代碼，在生成的時候，它會檢查父類有沒有聲明這個控件，如果聲明了，它會添加類似下面的一句代碼：

this.datagrid1 = __ctrl;
　　這個__ctrl就是生成該控件的變量，這時候它就把控件的引用賦給了父類中相應的變量，這也是為什么父類中的聲明必須為protected（實際上也可以為public），因為要保證子類能夠調用。

　　然后在執行page_load的時候，因為這時候父類的聲明已經被子類中的初始化代碼賦了值，所以我們就可以使用這個字段來訪問對應的控件，了解了這些，我們就不會犯在代碼綁定文件中的構造器里使用控件，造成空引用的異常的錯誤了，因為構造器是最先執行的，這時候子類的初始化還沒有開始，所以父類中的字段是空值，至于子類是什么時候初始化我們放到后面討論。

　五、頁面生存周期

　　現在回到第三個標題中講到的內容，我們講到了httpapplication的實例接收請求，并創建頁面類的實例，實際上這個實例也就是動態編譯的aspx的類的一個實例，上一個標題中我們了解到aspx實際上是代碼綁定中類的子類，所以它繼承了所有的protected方法。

　　現在我們來看看vs.net自動生成的codebehind類的代碼，以此來開始我們對頁面生命周期的探討：

#region web form designer generated code

override protected void oninit(eventargs e)
{
　//
　// codegen：該調用是 asp.net web 窗體設計器所必需的。
　//
　initializecomponent();
　base.oninit(e);
}

/// ＜summary＞
/// 設計器支持所需的方法 - 不要使用代碼編輯器修改
/// 此方法的內容。
/// ＜/summary＞

private void initializecomponent()
{
　this.datagrid1.itemdatabound += new system.web.ui.webcontrols.datagriditemeventhandler(this.datagrid1_itemdatabound);

　this.load += new system.eventhandler(this.page_load);
}

#endregion
　　這個就是使用vs.net產生的page的代碼，我們來看，這里面有兩個方法，一個是oninit，一個是initializecomponent，后者被前者調用，實際上這就是頁面初始化的開始，在initializecomponent中我們看到了控件的事件聲明和page的load聲明。

　　下面是從msdn中摘錄的一段描述和一個頁面生命周期方法和事件觸發的順序表：

　　“每次請求 asp.net 頁時，服務器就會加載一個 asp.net 頁，并在請求完成時卸載該頁。頁及其包含的服務器控件負責執行請求并將 html 呈現給客戶端。雖然客戶端和服務器之間的通訊是無狀態的和斷續的，但是必須使客戶感覺到這是一個連續執行的過程。”

　　“這種連續性假象是由 asp.net 頁框架、頁及其控件實現的。回發后，控件的行為必須看起來是從上次 web 請求結束的地方開始的。雖然 asp.net 頁框架可使執行狀態管理相對容易一些，但是為了獲得連續性效果，控件開發人員必須知道控件的執行順序。控件開發人員需要了解：在控件生命周期的各個階段，控件可使用哪些信息、保持哪些數據、控件呈現時處于哪種狀態。例如，在填充頁上的控件樹之前控件不能調用其父級。” “下表提供了控件生命周期中各階段的高級概述。有關詳細信息，請點擊表中的鏈接。”

階段控件需要執行的操作要重寫的方法或事件初始化初始化在傳入 web 請求生命周期內所需的設置。請參閱處理繼承的事件。init 事件（oninit 方法）加載視圖狀態在此階段結束時，就會自動填充控件的 viewstate 屬性，詳見維護控件中的狀態中的介紹。控件可以重寫 loadviewstate 方法的默認實現，以自定義狀態還原。loadviewstate 方法處理回發數據處理傳入窗體數據，并相應地更新屬性。請參閱處理回發數據。
注意只有處理回發數據的控件參與此階段。loadpostdata 方法（如果已實現ipostbackdatahandler）加載執行所有請求共有的操作，如設置數據庫查詢。此時，樹中的服務器控件已創建并初始化、狀態已還原并且窗體控件反映了客戶端的數據。請參閱處理繼承的事件。load 事件
（onload 方法）發送回發更改通知引發更改事件以響應當前和以前回發之間的狀態更改。請參閱處理回發數據。

注意只有引發回發更改事件的控件參與此階段。raisepostdatachangedevent 方法
（如果已實現 ipostbackdatahandler）處理回發事件處理引起回發的客戶端事件，并在服務器上引發相應的事件。請參閱捕獲回發事件。

注意只有處理回發事件的控件參與此階段。raisepostbackevent 方法
（如果已實現 ipostbackeventhandler）預呈現在呈現輸出之前執行任何更新。可以保存在預呈現階段對控件狀態所做的更改，而在呈現階段所對的更改則會丟失。請參閱處理繼承的事件。prerender 事件
（onprerender 方法）保存狀態在此階段后，自動將控件的 viewstate 屬性保持到字符串對象中。此字符串對象被發送到客戶端并作為隱藏變量發送回來。為了提高效率，控件可以重寫 saveviewstate 方法以修改 viewstate 屬性。請參閱維護控件中的狀態。saveviewstate 方法呈現生成呈現給客戶端的輸出。請參閱呈現 asp.net 服務器控件。render 方法處置執行銷毀控件前的所有最終清理操作。在此階段必須釋放對昂貴資源的引用，如數據庫鏈接。請參閱 asp.net 服務器控件中的方法。
dispose 方法卸載執行銷毀控件前的所有最終清理操作。控件作者通常在 dispose 中執行清除，而不處理此事件。 unload 事件（on unload 方法）
　　從這個表里面我們可以清楚的看到一個page從裝載到卸載之間調用的方法和觸發的時間，接下來我們就深入的對其進行一些分析。

　　看了上面的表，細心的朋友可能要問了，既然oninit是頁面生命周期的開始，而我們在上一講中談到控件在子類中被創建，那么在這里實際上在initializecomponent方法中我們已經可以使用父類中聲名的字段了，那么就意味著子類的初始化更在這之前？

　　在第三個標題中我們講到了頁面類的processrequest才是真正意義上的頁面聲明周期的開始，這個方法是由httpapplication調用的（其中調用的方式比較復雜，有機會單獨撰文來講解），一個page對請求的處理就是從這個方法開始，通過反編譯.net類庫來查看源代碼，我們發現在system.web.webcontrols.page的基類：system.web.webcontrols.templatecontrol（它是頁面和用戶控件的基類）中定義了一個“frameworkinitialize”虛擬方法，然后在page的processrequest中最先調用了這個方法，在生成器生成的aspx的源代碼中我們發現了這個方法的蹤影，所有的控件都在這個方法中被初始化，頁面的控件樹就在這個時候產生。

　　接下來的事情就簡單了，我們來逐步分析頁面生命周期的每一項：

　　1、初始化

　　初始化對應page的init事件和oninit方法。

　　如果要重寫，msdn推薦的方式是重載oninti方法，而不是增加一個init事件的代理，這兩者是有差別的，前者可以控制調用父類oninit方法的順序，而后者只能在父類的oninit后執行（實際上是在oninit里面被調用的）。

　　2、加載視圖狀態

　　這是個比較重要的方法，我們知道，對于每次請求，實際上是由不同的頁面類實例來處理的，為了保證兩次請求間的狀態，asp.net使用了viewstate。

　　loadviewstate方法就是從viewstate中獲取上一次的狀態，并依照頁面的控件樹的結構，用遞歸來遍歷整個樹，將對應的狀態恢復到每一個控件上。

　　3、處理回發數據

　　這個方法是用來檢查客戶端發回的控件數據的狀態是否發生了改變。方法的原型：

public virtual bool loadpostdata(string postdatakey, namevaluecollection postcollection)
　　postdatakey是標識控件的關鍵字（也就是postcollection中的key），postcollection是包含回發數據的集合，我們可以重寫這個方法，然后檢查回發的數據是否發生了變化，如果是則返回一個true，“如果控件狀態因回發而更改，則 loadpostdata 返回 true；否則返回 false。頁框架跟蹤所有返回 true 的控件并在這些控件上調用 raisepostdatachangedevent。”（摘自msdn）

　　這個方法是system.web.webcontrols.control中定義的，也是所有需要處理事件的自定義控件需要處理的方法，對于我們今天討論的page來說，可以不用管它。

　　4、加載

　　加載對應load事件和onload方法，對于這個事件，相信大多數朋友都會比較熟悉，用vs.net生成的頁面中的page_load方法就是響應load事件的方法，對于每一次請求，load事件都會觸發，page_load方法也就會執行，相信這也是大多數人了解asp.net的第一步。

　　page_load方法響應了load事件，這個事件是在system.web.webcontrol.control類中定義的（這個類是page和所有服務器控件的祖宗），并且在onload方法中被觸發。

　　很多人可能碰到過這樣的事情，寫了一個pagebase類，然后在page_load中來驗證用戶信息，結果發現不管驗證是否成功，子類頁面的page_load總是會先執行，這個時候很可能留下一些安全性的隱患，用戶可能在沒有得到驗證的情況下就執行了子類中的page_load方法。

　　出現這個問題的原因很簡單，因為page_load方法是在oninit中被添加到load事件中的，而子類的oninit方法中是先添加了load事件，然后再調用base.oninit，這樣就造成了子類的page_load被先添加，那么先執行了。

　　要解決這個問題也很簡單，有兩種方法：

　　1）在pagebase中重載onload方法，然后在onload中驗證用戶，然后調用base.onload，因為load事件是在onload中觸發，這樣我們就可以保證在觸發load事件之前驗證用戶。

　　2）在子類的oninit方法中先調用base.oninit，這樣來保證父類先執行page_load

　　5、發送回發更改通知

　　這個方法對應第3步的處理回發數據，如果處理回發數據返回true，頁面框架就會調用此方法來觸發數據更改的事件，所以自定義控件的回發數據更改事件需要在此方法中觸發。

　　同樣這個方法對于page來說，沒有太大的用處，當然你也可以在page的基礎上自己定義數據更改的事件，這當然也是可以的。

　　6、處理回發事件

　　這個方法是大多數服務器控件事件引發的地方，當請求中包含控件事件觸發的信息時（服務器控件的事件是另一個論題，我會在不久將來另外撰文討論），頁面控件會調用相應控件的raisepostbackevent方法來引發服務器端的事件。

　　這里又引出一個常見的問題：

　　經常有網友問，為什么修改提交后的數據并沒有更改

　　多數的情況都是他們沒有理解服務器事件的觸發流程，我們可以看出，觸發服務器事件是在page的load之后，也就是說頁面會先執行page_load，然后才會執行按鈕（這里以按鈕為例）的點擊事件，很多朋友都是在page_load中綁定數據，然后在按鈕事件中處理更改，這樣做有一個毛病，page_load永遠都是在按鈕事件之前執行，那么意味著數據還沒來得及更改，page_load中的數據綁定的代碼就先執行了，原有的數據又賦給了控件，那么執行按鈕事件的時候，實際上獲得的是原有的數據，那么更新當然就沒有效果了。

　　更改這個問題也非常簡單，比較合理的做法是把數據綁定的代碼寫成一個方法，我們假設為binddata：

private void binddata()
{
　//綁定數據
}
　　然后修改pageload：

private void page_load( object sender,eventargs e )
{
　if( !ispostback )
　{
　　binddata(); //在頁面第一次訪問的時候綁定數據
　}
}
　　最后在按鈕事件中：

private button1_click( object sender,eventargs e )
{
　//更新數據
　binddata();//重新綁定數據
}
　　7、預呈現

　　最終請求的處理都會轉變為發回服務器的響應，預呈現這個階段就是執行在最終呈現之前所作的狀態的更改，因為在呈現一個控件之前，我們必須根據它的屬性來產生html，比如style屬性，這是最典型的例子，在預呈現之前，我們可以更改一個控件的style，當執行預呈現的時候，我們就可以把style保存下來，作為呈現階段顯示html的樣式信息。

　　8、保存狀態

　　這個階段是針對加載狀態的，我們多次提到，請求之間是不同的實例在處理，所以我們需要把本次的頁面和控件的狀態保存起來，這個階段就是把狀態寫入viewstate的階段。

　　9、呈現

　　到這里，實際上頁面對請求的處理基本就告一段落了，在render方法中，會遞歸整個頁面的控件樹，依次調用render方法，把對應的html代碼寫入最終響應的流中。

　　10、處置

　　實際上就是dispose方法，在這個階段會釋放占用的資源，例如數據庫連接。

　　11、卸載

　　最后，頁面會執行onunload方法觸發unload事件，處理在頁面對象被銷毀之前的最后處理，實際上asp.net提供這個事件只是設計上的考慮，通常資源的釋放都會在dispose方法中完成，所以這個方法也變成雞肋了。

　　我們簡單的介紹了頁面的生存周期，對于服務器端事件的處理做了不太深入的講解，今天主要是想大家了解頁面執行的周期，對于服務器控件的事件和生存期我會在后續在寫一些文章來探討。

　　這些內容是我在學習asp.net的時候對page研究的一些心得，具體的細節沒有很詳細的探討，更多的內容請大家參考msdn，但是我舉了一些初學者常犯的錯誤和出現錯誤的原因，希望可以給大家帶來啟發。

商業源碼熱門下載www.html.org.cn

上一篇：使用ASP.NET程序來管理文件或目錄的一種方案

下一篇：ASP.net中用axWebBrowser中提交表單