ASP.NET頁面解析(3)

事件模型

當某個頁面被請求時，它的類及其所包含的伺服器控制項會負責處理請求，呈現HTML輸出，並隨後發回用戶端。由於HTTP協議的固有特性，用戶端與伺服器間的通訊是無狀態且非串連的。而實際的應用程式需要狀態，以便維護對同一頁面的後續調用。使用ASP或其他伺服器端開發平台(如Java Server Page和LAMP一類的基於Linux的系統)，開發人員必須負責狀態的儲存。而ASP.NET提供了一種內建架構，能夠以透明的方式對頁面的狀態進行儲存和恢複。儘管基於無狀態的協議，但以這種方式，從用戶端體驗到的是連續的執行過程。然而，那隻是一種表象。

檢視狀態簡介

連續性所導致的這種表象，一方面與頁面的設計和工作方式有關，另一方面是ASP.NET整頁模式狀態造成的。與此同時，伺服器端控制項也發揮著重要作用。簡而言之，在頁面將其內容呈現為HTML之前，頁面要將自身及其所包含的控制項的狀態資訊儲存在持久性介質(一般為隱含欄位)中。當該頁面回傳後，其狀態會從隱含欄位中被還原序列化，用於對聲明在頁面配置中的伺服器控制項執行個體進行初始化。 每個頁面執行個體有其特有的檢視狀態，因為該資訊嵌入在HTML中。這樣做的好處是，控制項會以上一次建立的檢視狀態(即該頁最後一次被呈現發送到用戶端時的狀態)的值進行初始化。此外，頁面周期中還會有一個階段，將已儲存的狀態與由用戶端做出的更新合并。在回傳後，頁面執行時，它會發現一個有狀態的且更新過的上下文，就像工作在連續的點對點連接上一樣。 這裡做了兩個假設。第一個假設是，頁面總是投遞給自身，並攜帶著狀態資訊。第二個假設是，伺服器端控制項必須帶有runat=server屬性，以便在頁面回傳後具有“生命力”。

單表單模型

不可否認，對於具有ASP或JSP經驗的程式員來說，開始可能不太適應ASP.NET的單表單模型。這些程式員在論壇和新聞群組經常會問這樣的問題：“表單的Action屬性在哪裡？”以及“為什麼我提交表單時，不能重新導向到一個特定頁面？” ASP.NET頁面只支援一個伺服器端<form>(表單)標籤。所有要與伺服器互動的控制項，必須全部置於在該表單中。表單和控制項都必須帶有runat屬性，否則會被視為純文字，並被逐字輸出。在伺服器端，表單是HtmlForm類的執行個體。HtmlForm類沒有暴露任何相當於HTML <form>標籤的Action的屬性。其原因在於，ASP.NET頁面總是投遞給自己。除Action屬性外，表單其他常用屬性(如Method和Target)還是完全支援的。 不包含伺服器端表單的，以及使用HTML表單(不帶runat屬性的<form>標籤)的頁面，也是有效ASP.NET頁面。在ASP.NET頁面中，HTML和伺服器表單可以同時存在。然而只能有一個<form>標籤的runat屬性設定為server。HTML表單會像一般情況一樣，使我們能夠向程式中的任何頁面投遞。但這樣的做問題在於，狀態資訊不會被自動儲存。換言之，僅當表單使用一個伺服器<form>元素時，ASP.NET Web表單模型才會工作.

非同步頁面

ASP.NET頁面會被HTTP處理常式作為Page類的執行個體處理。每個請求會佔用ASP.NET線程池中的一個線程，在請求完畢後該線程才會被釋放。倘若被請求的頁面頻繁地啟動外部的、高耗時的任務呢？問題在於，ASP.NET進程雖然閑置，但池中沒有閒置線程來處理新入的其他頁面的請求。這多應歸因於HTTP處理常式(包括頁面類)的同步工作方式。為減輕這個問題，自1.0版開始，ASP.NET支援了非同步處理常式(通過IHTTPAsyncHandler介面)。而從ASP.NET 2.0版開始，由於有了架構的支援，建立非同步頁面變得更加容易了。 非同步ASP.NET頁面的構建涉及兩個方面：@Page指令的一個新屬性以及註冊的若干非同步執行的任務。非同步任務可以通過兩種途徑註冊。可以為PreRenderComplete事件定義非同步處理常式Begin/End對兒，也可以建立代表非同步任務的PageAsyncTask對象。這在PreRender事件被引發之前進行就可以，但一般是在Page_Load事件中。