事件模型

當某個頁面被請求時，它的類及其所包含的服務器控件會負責處理請求，呈現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事件中。

轉載于:https://www.cnblogs.com/gaoweipeng/archive/2010/03/08/1680737.html

總結

以上是生活随笔為你收集整理的ASP.NET页面解析(3)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。