下載本文的代碼：[url=http://download.microsoft.com/download/4/b/4/4b44505a-ecda-4dd3-8a0e-71d8c7a8b9bb/ASPColumn0311.exe]ASPColumn0311.exe[/url] (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 是為處理 HTTP 請求而設計的類庫。除了類庫，ASP.NET 還包含幾個管理請求的 IIS 組件。這些組件包括名為 ASPNET_ISAPI.DLL 的 ISAPI DLL 以及名為 ASPNET_WP.EXE 的輔助進程。ASP.NET 還在 IIS 中安裝了新的映射，將 ASPX、ASCX、ASHX 和 ASMX 的文件請求重定向到 ASPNET_ISAPI.DLL。至此，ASPNET_ISAPI.DLL 將請求定向到 ASPNET_WP.EXE，在該進程中，ASP.Net 加載所需要的類來為請求提供服務。
以名稱為 HttpContext 的托管類為中心，ASP.NET 有一個很方便的對象模型。如果您曾經寫過一個標准的 ISAPI DLL，那麼您一定了解包含於 EXTENSION_CONTROL_BLOCK 中並傳遞給 ISAPI DLL 的 HttpExtensionProc 的信息。管理請求時，ISAPI DLL 對該結構進行檢查，以獲得諸如環境 ID、查詢字符串，以及讀寫客戶端的函數等信息。ASP.NET 將所有這些信息都包裝在 HttpContext 類中。ASP.Net 還包括管理基於 Web 的 UI（通過 System.Web.UI.Page 類）以及管理 Web 服務（通過 System.Web.Services.WebService 類和 [WebMethod] 屬性）的基本類結構。
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 示例中的用戶界面大致相同。
本文件中需要注意的最重要的事項是由雙大括號括起來的特殊標記。例如，在 SRF 的頂端附近，您會看到指定應用程序默認處理程序的處理程序標記 ({{handler...}})。這會告訴 ATL Server 應用程序加載哪一個 DLL，以找到由響應標記調用的函數。其它的響應標記指出應用程序 DLL 中的入口點。
返回頁首返回頁首
“固有”對象
ASP.NET 和 ATL Server 都包含有類似的固有請求和響應對象，這和典型的 ASP Ò»Ñù&IExcl;£在 ASP.NET 中，它們用 HttpRequest 和 HttpResponse 類來表示。在 ATL Server 中，它們用 CHttpRequest 和 CHttpResponse 類來表示。在每種框架中，它們的用途基本相同。請求對象封裝了諸如請求參數和請求 URL 等項。響應對象包含有向客戶端輸出文本的功能。例如，為了向某個基於 ASP.Net 請求的輸出流插入“Hello World”，只需要調用 Response.Write 即可，如下所示：
protected void HelloWorld()
{
Response.Write("Hello World");
}
為了向基於 ATL Server 應用程序的客戶端輸出“Hello World”，使用 CHttpResponse 對象，如下所示：
[tag_name(name="Hello") ]
HTTP_CODE OnHello(void) {
m_HttpResponse << "Hello World!";
return HTTP_SUCCESS;
}
要注意如何利用圖 5中的服務器響應標記來調用 OnHello 函數。（這個標記如下所示：Hello。）
返回頁首返回頁首
管理 UI 元素
每種框架采用了不同的方法來管理 UI 元素。正如以前提到的那樣，ASP.Net 中的 UI 支持圍繞著服務器端控件模型。表示代碼（ASPX 文件）利用“runat=server”屬性聲明了網頁上的服務器端元素。只要在代碼隱藏類中聲明了相應的類，以編程方式訪問控件就輕而易舉了。例如，圖 4中的代碼說明了幾種服務器端控件元素（例如，提交按鈕、文本框元素，以及下拉列表）。代碼隱藏頁將 Button、TextBox 和 DropDownList 類聲明為該頁的成員，使得可以編程使用這些 UI 元素。為了找到 TextBoxName 元素中的數據，只需要訪問 Text 屬性即可，如下所示：
String s = this.TextBoxName.Text;
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++ 編寫，因此您就擁有許多控制權和必要的責任。
