asp.net|server 下載本文的代碼：ASPColumn0311.exe (534KB)
*
本頁內容
ASP.NET 究竟是什嗎？ ASP.NET 究竟是什嗎？
ATL Server 有何不同？ ATL Server 有何不同？
ATL Server 與 ASP .NET ATL Server 與 ASP .NET
ASPX 檔案與 SRF ASPX 檔案與 SRF
“固有”對象 “固有”對象
管理 UI 元素 管理 UI 元素
工作階段狀態 工作階段狀態
小結 小結
Web 服務器的任務就是接受傳入的 HTTP 要求，並返回一些對來電者有用的資訊（不論來電者是人，或者是 Web 服務時的機器）。Windows 包含有處理請求的成熟結構 — IIS 及其相關擴充。但是，從頭開始設計 IIS 是很單調乏味的，並且容易出錯。管理 HTTP 要求的一種較好的方法就是利用位於 IIS 頂部的一種架構來管理。本月我將比較兩種建立 Windows Web 應用程式的主要技術：ASP.NET 與 ATL Server。每種架構都有一些特定的優缺點。在本部分，我將集中講述如何用 ASP.NET 管理基於 Web 的 UI。下次我將集中講述如何利用這兩種架構來構建 Web 服務及其它功能。
ASP.NET 究竟是什嗎？
ASP.NET 是物件導向的。每個通過 ASP.NET 應用程式傳遞的請求都由名為 IHttpHandler 的類來處理，該類可以實現介面。這樣就造就了一種擴充性很強的體繫結構。您可以選擇利用 ASP.NET 頁體繫結構或 Web 服務體繫結構，或者，您還可以從頭編寫處理邏輯。圖 1 顯示了 ASP.NET 請求採取的路徑。
MIissues0311ASPColumnfig01
圖 1 ASP.NET 請求的生命週期
ASP.NET UI-處理體繫結構以 Web.UI.Page 類（由 ASPX 檔案表示）為中心。ASPX 檔案可以包括整齊的 HTML 程式碼及伺服器端控制項。當 ASP.NET 遇到一個伺服器端控制項時（通過“runat=server”屬性），它就執行個體化了一個表示該控制項的類（例如，Button 和 ListBox 控制項）。本質上，ASP.NET 頁作為這些伺服器端控制項的樹來處理（該頁上的文本和標記被打包為 LiteralControl 類）— 其它的都是伺服器端控制項。當要求呈現該頁自身時，該頁只是遍曆該控制樹，“告訴”樹上的每個節點呈現它們自身。ATL Server 的運作方式有些不同。
返回頁首返回頁首
ATL Server 有何不同？
ATL Server 是一個用來建立 ISAPI DLL 的 C++ 範本庫。當第一次建立 IIS 時，開發人員必須從頭或從 MFC 的 ISAPI DLL 類作為起點來編寫 ISAPI 擴充。利用原始的 C++ 或 MFC 代碼產生 ISAPI DLL 需要人工編寫擴充代碼。例如，MFC ISAPI 沒有為開發人員提供基於表單的體繫結構。任何在用戶端結束的 HTML 標籤都必須由人工來發出。
ATL Server 將基於表單的方法與運行時速度以及 C++ 的靈活性結合起來。利用 ATL Server 構建的 Web 網站由三個基本組件構成：伺服器回應檔 (SRF)、應用程式 DLL 以及必備的 ISAPI 擴充。SRF 是 ATL Server 安裝在 IIS 中的一種新型檔案。SRF 映射將 IIS 指嚮應用程式的 ISAPI DLL，這反過來又將處理指向一個或多個應用程式 DLL。SRF 包括一種特殊的新的標記文法，它本質上是在應用程式 DLL 中調用進入點。圖 2 顯示了基於 ATL Server 的請求通過系統時所採用的路徑。
MIissues0311ASPColumnfig02
圖 2 基於 ATL Server 的請求的路徑
ATL Server 應用程式由許多 DLL（ISAPI 擴充和應用程式擴充）以及被稱為 SRF（前面提到過）的 HTML 產生模板組成。這種體繫結構很清楚地將應用程式表示和應用程式邏輯分離開來。網頁的表示由包含 HTML 和特殊標記的 SRF 來定義。這些標記調用 ATL Server 應用程式 DLL。
由於大多數 Web 應用程式的目標平台是 Windows，因此 ATL Server 應用程式要構建於 ISAPI DLL 之上。ATL Server 項目包含可處理粗略請求的單個 ISAPI 擴充 DLL。ATL Server 應用程式還包含用於多種精確請求處理的一個或多個應用程式 DLL。處理請求的類派生於 CRequestHandlerT，並且還包含您自己特有的、用來處理 SRF 中標記的代碼。
這些處理常式類包含將請求處理常式類和請求處理常式 DLL 關聯起來以及將替代方法與 SRF 標記關聯起來的字典。除了替代字典外，CRequestHandlerT 還包含訪問標準 Web 應用程式元素的方法和成員變數，例如表單變數、cookies、請求流以及響應流。
當瀏覽器通過 HTTP 找到 .srf URL 時，IIS 知道用 ATL Server 應用程式的 ISAPI DLL 來開啟網站。ATL Server 應用程式隨後開啟 SRF，並載入該應用程式的 DLL（如果它們還沒有載入的話）。該應用程式隨後將請求傳送到預設的請求處理常式類，該類對 SRF 進行分析，以尋找有特殊記號的標記。每次在 SRF 中出現標記時，應用程式就調用存在於某應用程式 DLL 中某個處理常式類的替代方法。該替代方法動態產生瀏覽器的輸出。圖 2 顯示了通過 ATL Server 應用程式的請求的路徑。
返回頁首返回頁首
ATL Server 與 ASP .NET
雖然 ATL Server 和 ASP.NET 都基於 ISAPI 體繫結構，但是它們處理請求有很大不同。為了說明這些不同點，讓我們看一個應用程式樣本，該應用程式收集個人姓名和他（或她）的開發偏好。我將說明如何開發使用者介面以及如何使用工作階段狀態。在本專欄的下一部分，我將考察其他的一些功能（例如緩衝和瀏覽器的能力），以及每種架構上 Web 服務的工作原理。圖 3 對比了兩種架構的一些功能。
返回頁首返回頁首
ASPX 檔案與 SRF
ASP.NET 和 ATL Server 為 ISAPI 體繫結構引入了新的副檔名。ASP.NET 引入的檔案類型有 ASPX、ASMX、ASCX 和 ASHX，還有一些其它類型。在 ASP.NET 架構中，這些檔案類型中的每一種都有一個對應的託管類。對於 ASPX 檔案來說，這樣的類就是 System.Web.UI.Page。該 Page 類負責呈現基於 UI 的網頁。圖 4 顯示了一個簡單的 ASPX 檔案。
關於 ASPX 檔案要注意的主要事項就是，網頁頂端附近的繼承指令以及按鈕、標籤和下拉式清單標記的“runat=server”屬性。這些標記表示了伺服器端控制項在 Visual Studio 中的程式碼後置檔案中對應的類。
相比之下，SRF 包含了最標準、最普通的 HTML 標籤。ATL Server 沒有伺服器端組件體繫結構。但是，它確實引入了伺服器響應標記的概念。這些特殊的標記用雙大括弧 ({{}}) 表示。當 ATL Server 請求體繫結構遇到一個伺服器響應標記時，它期望在應用程式 DLL ÖÐ找到一個對應的處理常式函數。圖 5 顯示了一個簡單的 SRF，它顯示的使用者介面與圖 4 ASPX 樣本中的使用者介面大致相同。
ASP.NET 和 ATL Server 都包含有類似的固有請求和響應對象，這和典型的 ASP Ò»Ñù¡£在 ASP.NET 中，它們用 HttpRequest 和 HttpResponse 類來表示。在 ATL Server 中，它們用 CHttpRequest 和 CHttpResponse 類來表示。在每種架構中，它們的用途基本相同。請求對象封裝了諸如請求參數和請求 URL 等項。響應對象包含有向用戶端輸出文本的功能。例如，為了向某個基於 ASP.NET 請求的輸出資料流插入“Hello World”，只需要調用 Response.Write 即可，如下所示：
ASP.NET 伺服器端控制項還有自動跟蹤檢視狀態的優點。當瀏覽器往返訪問伺服器時，UI 元素（如下拉式清單方塊和選項按鈕）會保持它們一致的狀態。例如，最後一次在下拉式清單方塊中選擇的項就是顯示的項。不需要編寫任何特殊的代碼來保證控制項的行為正確。
ATL Server 沒有這樣的控制項模型。只能通過伺服器響應標記來管理 UI。為了填充下拉式清單，ATL Server 樣本中用一個伺服器響應函數來填充它（參見圖 5中的{{ShowFeatureSelection}} 標記。圖 6 說明了伺服器響應函數是如何將各項插入到下拉式清單的。
ATL Server 與 ASP.NET 的方法不同，它不跟蹤視圖的狀態。為了保持下拉式清單的一致性，需要圖 6中顯示的代碼。這些代碼檢查查詢字串傳入的參數，並找出選擇了哪一項。呈現代碼確保使用者選擇的項在選項標記中包含“被選”屬性。
返回頁首返回頁首
工作階段狀態
在 ASP.NET 中管理工作階段狀態非常便利。ASP.NET 輔助進程處理低級的細節問題。當某個新用戶端啟動一個會話時，ASP.NET 將自動分配一個新會話對象 — 包含名稱-值對的字典。System.Web.UI.Page 類包含一個目前客戶會話資訊的引用。訪問客戶的狀態只需要利用索引器來訪問會話字典即可。圖 7 顯示了建立新會話變數以及以後利用 ASP.NET 訪問它們所需要的代碼。
在 ATL Server 中，管理工作階段狀態稍微有點複雜。雖然利用 ATL Server 嚮導產生 ISAPI DLL 時包括一個會話管理器，但您仍需要編寫代碼來建立和訪問會話對象。圖 8 中的代碼說明了如何在 ATL Server 中建立和訪問會話變數。
由 ATL Server 嚮導產生 ValidateAndExchange 函數。在每個請求的開始調用該方法，就像 ASP.NET Page 類中包含的 Init 與 Load 事件一樣。ValidateAndExchange 為 ISAPI DLL 的會話管理器獲得一個介面（通過 QueryService）。如果在標題中還沒有會話 cookie，該方法就建立一個新會話，並為響應添加一個會話 cookie。如果這是現有會話的繼續，這些代碼就會利用會話資訊來填充名稱和年齡變數。注意，會話變數用 COM 變數表示。
返回頁首返回頁首
小結
本月，我快速探索了 ASP.NET 和 ATL Server。這些架構代表了當前處理 Windows 平台上 HTTP 要求的最先進的方法。每種架構都構建於久經測試的 ISAPI 體繫結構之上，該體繫結構幾乎在十年前就已出現。ASP.NET 和 ATL Server 將它們的副檔名映射到特定的 DLL。ASP.NET DLL 就是 ASPNET_ISAPI.DLL。 ATL Server DLL 由 ATL Server 產生，但是對於它的大部分來說，它是可反覆套用的代碼。在這方面，ATL Server 的一個優點就是，實際上可以查閱（和更改）特殊應用程式的原始的 ISAPI 請求處理代碼。
雖然可以使用任何一種架構來編寫大體上等同的應用程式，但這裡需要折中考慮標準問題。通常，利用一種託管語言和 ASP.NET 架構來開發 ASP.NET 應用程式非常直接。但是，您會受該架構的支配（儘管 ASP.NET 利用其可擴充性已經緩和了靈活性問題）。另一方面，只要 ATL Server 應用程式通過了 IIS 的考驗，它就包含了大多數 DLL µ÷ÓÃ — 一條高效能的建議。ATL Server 應用程式用 C++ 編寫，因此您就擁有許多控制權和必要的責任。
下一次我將對比 ASP.NET 與 ATL Server 的其它功能，包括緩衝狀態、安全性和 Web 服務。
圖3到圖8的連結：http://www.msdn.microsoft.com/msdnmag/issues/03/11/ASPColumn/default.aspx?fig=true#fig3
George Shepherd 專門從事 .NET Framework 軟體的開發。他是 Programming with Microsoft Visual C++.NET (Microsoft Press, 2002) 的作者，並且還是 Applied .NET (Addison-Wesley，2001) 的合著者。他在研討會上講授 DevelopMentor，他還是一位在 Syncfusion 的 .NET 工具方面很有貢獻的構架師。
