應用程序設計指南：從N層到 .NET

　　摘要：討論 Microsoft .NET 的應用程序設計和所需的更改：檢驗從使用 Microsoft Windows DNA 構建 N 層應用程序中學到的結構知識，以及如何將這些知識應用到使用 Microsoft .NET 框架構建的應用程序，并且為使用 XML Web services 的應用程序提供體系結構方面的建議。

　　如今，N 層應用程序已經成為構建企業軟件的標準。對于大多數人來說，N 層應用程序就是被分成多個獨立的邏輯部分的應用程序。最常見的選擇是分為三個部分：表示、業務邏輯和數據，當然還可能存在其他的劃分方法。N 層應用程序最初是為了解決與傳統的客戶端/服務器應用程序相關的問題而出現的，但是，隨著 Web 時代的到來，這一體系結構開始成為新開發項目的主流。

　　Microsoft Windows® DNA 技術已成為 N 層應用程序的非常成功的基礎。Microsoft .NET 框架也為構建 N 層應用程序提供了堅實的平臺。然而，.NET 所帶來的變化使結構設計人員應當重新考慮他們在 Windows DNA 領域中所學的有關設計 N 層應用程序的某些知識。更重要的是，對內置于 .NET 框架的 XML Web services 的基本支持允許開發人員構建突破傳統 N 層方法的新應用程序。要了解如何更好地構建 .NET 應用程序的體系結構，您需要了解這一新領域中發生了哪些變化，以及如何充分利用這些變化。

　　本文將對這些問題進行討論。首先回顧一下在使用 Windows DNA 構建 N 層應用程序中學到的關鍵體系結構知識。然后，再按同一順序將這些知識應用到使用 .NET 框架構建應用程序的過程中，從而對它們進行檢驗。最后一部分對使用 XML Web services 的應用程序的體系結構提供了一些建議。

　　將應用程序分解成多個邏輯部分是很有用的。將一個大軟件分成幾個小的部分會更利于軟件的構建、重復利用和修改，對適應不同的技術或不同的業務組織也很有幫助。同時，還有一些綜合因素需要考慮。雖然模塊化和重復使用性很有效，但它們可能會導致應用程序不能象使用其他方法那樣安全、易管理和快速。本節將回顧一些從使用 Windows DNA 技術構建 N 層應用程序的普遍經驗中所獲得的基本體系結構知識。

　　Windows DNA 應用程序通常使用以下三種實現方式中的一種或多種方式來實現其業務邏輯：

• ASP 頁
• COM 組件，可能使用 COM+ 提供的其他服務
• 在 DBMS 中運行的存儲過程

　　一般來講，在 ASP 頁中編寫過多的業務邏輯并不是一個好辦法。因為必須使用簡單的語言，例如 Microsoft Visual Basic® Script (VBScript)，而且每次執行時都要解釋代碼，這會對性能造成影響。而且 ASP 頁中的代碼不好維護，主要是因為業務邏輯通常與創建用戶界面的表示代碼混合在一起。

　　鑒于這種情況，建議在編寫中間層業務邏輯時，將業務邏輯當作 COM 對象來實現。這種方法比編寫純粹的 ASP 應用程序要稍微復雜一點，但是可以使用全功能語言來生成編譯好的可執行文件，因此其結果要快得多。將業務邏輯包裝在 COM 對象中還可以將此代碼與包含在 ASP 頁中的表示代碼完全分隔開來，從而使應用程序更易于維護。

　　從 COM 到 COM+，其體系結構相差無幾。但是，正如許多 Windows DNA 體系結構設計人員所了解的，除非真正需要，否則不應使用 COM+ 提供的核心服務，如事務、實時 (JIT) 激活、基于角色的安全性和線程服務等。使用其他開發平臺提供的 COM+ 或類似服務自然會導致應用程序速度更慢、更復雜。只有在以下情況下使用 COM+ 才有意義：

• 需要跨越不同資源管理器（如 Microsoft SQL Server™ 和 Oracle）的分布式事務。
• 應用程序可以有效地利用基于角色的安全性。
• 可以增強 Microsoft Visual Basic® 6.0 的線程操作。
• JIT 激活能夠提高性能；瀏覽器客戶端很少出現這種情況，因為 ASP 頁是通過 JIT 有效激活的。
• COM+ 的配置優勢大大簡化了應用程序的部署。

　　編寫業務邏輯的第三種方式是，創建一些作為存儲過程在數據庫管理系統 (DBMS) 中運行的代碼。盡管使用存儲過程的主要原因是將數據庫架構的詳細信息與業務邏輯分隔開以簡化代碼的管理和提高安全性，但代碼與數據如此接近也有助于優化性能。那些必須獨立于 DBMS 的應用程序（例如由獨立的軟件供應商創建的應用程序）通常要避免使用這種方法，因為它會將應用程序鎖定到某個特定的數據庫系統中。存儲過程的編寫和調試可能會比 COM 對象的編寫和調試難，而且此方法會減少重復使用代碼的機會，這是因為 COM 對象通常比存儲過程更易于重復使用。但是大多數自定義應用程序仍然連接到最初創建它們的 DBMS 上，因此使用存儲過程的性能優勢還是很大的。鑒于這種情況，那些必須盡可能運行良好的 Windows DNA 應用程序通常對部分或全部的業務邏輯都使用存儲過程。

　　Windows DNA 既支持用 Visual Basic 等語言編寫的本地 Windows 客戶端，也支持瀏覽器客戶端。瀏覽器客戶端的局限性較大，尤其同時將 Microsoft Internet Explorer 和 Netscape 作為瀏覽器時。因此，應用程序通常同時擁有瀏覽器客戶端和本地 Windows 客戶端。瀏覽器客戶端提供的界面很有限，但用它可以方便地訪問 Internet，而 Windows 客戶端能提供全功能的界面。使用可下載的 Microsoft ActiveX® 控件可以創建更復雜的瀏覽器界面，但必須確保瀏覽器是 Internet Explorer，并且用戶愿意信任應用程序的創建者。

　　ASP 應用程序可以使用幾個不同的機制來維護服務器上客戶端請求之間的信息。但是 Windows DNA 中有一條嚴格的規則，如果應用程序在兩臺或多臺機器之間平衡負載，則絕對不能使用 ASP Session 對象存儲每個客戶端的狀態。ASP 的 Session 對象被鎖定在一臺機器上，因此不能用于負載平衡的應用程序。

　　ASP Session 對象和 ASP Application 對象還有另一個限制。使用它們中的任何一個來存儲 ADO 記錄集都會大大降低可伸縮性，因為它限制了應用程序開發多線程的能力。因此，在這兩個對象的任何一個中存儲記錄集都不是好辦法。

　　在 Windows DNA 中，選擇運行在不同機器上的組件的通信方式非常簡單：DCOM 可以說是唯一的選擇。單純從體系結構上來看，DCOM 是 COM 的簡單擴展。但實際上，DCOM 還有許多其他含義，其中包括：

• 由于實際上是其自有協議，因而使用 DCOM 與遠程 COM+ 對象進行通信非常直接。
• 只要配置正確，DCOM 將是非常安全的協議。但是要實現這種配置并不容易，因此該協議不太容易使用。盡管如此，DCOM 自身仍能提供很好的分布式身份驗證、數據完整性和數據保密性，特別是在 Windows 2000 域內。
• 由于 DCOM 需要打開任意端口，因此不適合與防火墻配合使用。所以，對于必須通過 Internet 進行通信的應用程序，一般不能使用 DCOM。

　　可以將使用 ADO 構建的數據訪問體系結構分為兩類：輕型和重型。輕型 ADO 客戶端盡可能簡短地保持數據庫連接，并使用存儲過程寫入數據庫。輕型客戶端使用以下三種方法之一檢索數據：

• 通過使用只讀的、僅向前游標填充記錄集；
• 通過存儲過程輸出參數；
• 使用數據流（在 ADO 的較新版本中）。

　　重型客戶端則會較長時間地保持數據庫連接。這類應用程序依賴于開放式連接，以及那些連接所允許的有狀態的服務器端游標，以：

• 使記錄集能夠直接訪問其他用戶或應用程序所做的更改；
• 啟用保守式鎖定；
• 盡可能減少復制到 ADO 客戶端的數據量，以減少網絡通信量。與輕型客戶端不同，使用服務器端游標的客戶端可以將查詢結果保留在數據庫內，直到真正需要這些數據時再取出。此外，這種方法向記錄集復制的元數據較少，而把更多的數據保留在數據庫中。

　　輕型應用程序最具伸縮性，因為它們最有效地使用了數據庫連接這一稀有資源。相比之下，重型應用程序必須保持長期有效的數據庫連接，因為這是有狀態的服務器端游標所要求的。這就大大地限制了應用程序的可伸縮性，尤其不適用于 Internet 服務器應用程序。盡管使用 ADO 開發重型應用程序可能更簡單，但通常這并不是最佳選擇。

　　ADO 也不是特別適用于處理 XML 文檔等分層數據。ADO 完成此項工作的功能用法復雜，且不易理解。同樣，ADO 僅為訪問 SQL Server 2000 的 XML 功能提供有限支持，因此，Windows DNA 應用程序通常都避免使用 ADO 處理分層數據。

　　對于所有 N 層應用程序而言，將數據從中間層有效地移動到客戶端都是一個關鍵的環節。當使用 DCOM 與 Windows 客戶端通信時，Windows DNA 應用程序可以使用 ADO 斷開連接的記錄集。當確保瀏覽器為 Internet Explorer 時，此選項也可用于瀏覽器客戶端。而將數據發送到任意瀏覽器則比較困難。一種方法是顯式地將數據轉換為 XML，然后將數據和所有必要的腳本代碼發送到瀏覽器。

　　.NET 支持傳統的 N 層應用程序、Web services 應用程序以及將二者的元素結合在一起的應用程序。本節首先介紹 .NET 如何影響 N 層應用程序，然后介紹構建 Web services 應用程序過程中的幾個主要的體系結構問題。

　　上一節中介紹的某些問題同樣適用于 Windows DNA 應用程序和使用 .NET 框架構建的應用程序。例如，只有當滿足前面所列的一個或多個條件時，才能使用 COM+（在 .NET 框架中稱為企業服務）。同樣，將業務邏輯構建為存儲過程在很多 N 層應用程序中都可以獲得更好的性能。

　　同時，.NET 框架中到處都是新技術和現有技術的新版本。這些增強功能為 N 層應用程序的優化體系結構帶來了多種變化。本節將按照前面介紹的分類，介紹 .NET 框架是如何改變體系結構設計人員在創建 N 層應用程序時所做的決定的。

　　與在 Windows DNA 中創建 N 層業務邏輯的三種可選方法（ASP 頁、COM 組件和存儲過程）不同，.NET 框架只提供了兩種方法：程序集和存儲過程。對于瀏覽器應用程序，可以使用 Microsoft ASP.NET .aspx 頁來創建程序集。與 ASP 不同，在這種情況下完全使用 ASP.NET 編寫業務邏輯通常是一個比較好的方法。

　　其中一個原因就是 ASP.NET 的內含代碼選項。在傳統的 ASP 頁中，以一種可維護的方式混合業務代碼和表示代碼并不是一件容易的事，而 .aspx 頁使用內含代碼能夠完全將這兩種代碼分開。Windows DNA 應用程序可能需要同時使用 ASP 頁和 COM 對象才能實現可維護性，而使用 .NET 框架構建的應用程序則只需使用 ASP.NET。此外，.aspx 頁中包含的業務邏輯可以用任何基于 .NET 的語言編寫，而不僅限于傳統 ASP 頁所支持的簡單的腳本語言。而且，ASP.NET 是編譯頁面而不是解釋頁面，因此 ASP.NET 應用程序速度可以非?？?。雖然使用 Windows DNA 構建的應用程序可以使用 ASP 頁和 COM 對象來達到足夠高的性能，但 .NET 只需使用 ASP.NET 便可構建具有同樣優良性能的應用程序。最后，業務邏輯使用 ASP.NET 緩存來減少對包含常用數據的數據庫的訪問，這樣可以大大提高性能。

　　但是，需要指出的是，對于包含在 .aspx 頁中的代碼，即使是使用內含代碼，其重復使用也比標準的程序集困難。例如，從 Windows 窗體客戶端訪問 .aspx 頁中的代碼會遇到很多問題。

　　使用 .NET 框架可減少對 Windows 客戶端的需求，通常只需要一個瀏覽器客戶端即可。其中一個原因在于，ASP.NET Web 控件允許構建和/或購買可重復使用的瀏覽器圖形用戶界面 (GUI) 元素，從而能夠更方便地構建更有用的瀏覽器客戶端。而且可以將基于 .NET 框架的組件下載到 Internet Explorer 客戶端，然后使用部分信任來運行這些組件（而不使用 ActiveX 控件所要求的全是全非信任模式），這有助于構建更好的用戶界面。

　　由于 ASP Session 對象被綁定到一臺機器上，因此它并未發揮出應有的作用，而使用 .NET 框架就避免了這種限制。與 ASP 不同，ASP.NET Session 對象可以被兩臺或多臺機器共享，從而可以使用 Session 對象來維護負載平衡的 Web 服務器領域中的狀態，使其更加有用。而且，由于 Session 對象的內容可以選擇存儲在 SQL Server 數據庫中，這種機制可用于出現故障時必須一直保持每個客戶端的狀態的應用程序中。

　　影響 ASP.NET 應用程序體系結構的另一個重要更改在于，數據集可以存儲在 Session 和 Application 對象中而無需包含線程，這一點與 ASP 不同。也就是說，在 Windows DNA 中嚴格規定的不能將記錄集存儲在這些對象中的規則不適用于 .NET 框架中的數據集。這就使得查詢結果的存儲更加簡單也更加自然。

　　與 Windows DNA 相比，.NET 框架為應用程序的分布式部件之間的通信提供了更多選擇，包括：

• .NET Remoting，提供 TCP 通道和 HTTP 通道；
• ASP.NET 支持在 .asmx 頁中實現的、可通過 SOAP 調用的 XML Web services；
• 與遠程 COM 對象通信所需的 DCOM。

　　選項越多，意味著體系結構的選擇也越多，這也意味著做選擇時有更多需要考慮的因素。使用 .NET 框架創建分布式應用程序時要了解的體系結構問題包括：

• 直接與遠程 COM+ 對象進行通信要求使用 DCOM，而不能使用 .NET Remoting。由于 DCOM 的建立和使用都相當復雜，因此應盡量避免這種通信。在某些情況下，有必要通過托管代碼處理現有的 COM+ 對象，盡管這樣做所要求的 COM 互操作性會降低性能。
• .NET Remoting TCP 通道沒有提供內置的安全性。與 DCOM 不同，它不提供嚴格的身份驗證、數據完整性或數據保密服務。但它并非一無是處，TCP 通道比 DCOM 更容易配置。
• DCOM 不能很好地與防火墻配合使用，.NET Remoting HTTP 通道與之不同，它是專門為在 Internet 上進行有效通信而設計的。而且，由于可以使用 SSL，此選項能夠為數據提供安全的路徑。通常，對于 Intranet 通信而言，TCP 通道是較好的選擇；而對于 Internet 通信，則更適合使用 HTTP 通道或 ASP.NET SOAP 支持。
• .NET Remoting HTTP 通道和用于 XML Web services 的 ASP.NET 支持都能實現 SOAP。但這兩種實現卻截然不同，各有其特定的目的。.NET Remoting 注重保持公共語言運行時的確切語義，因此當遠程系統也運行 .NET 框架時，它是最佳選擇。ASP.NET 則注重提供絕對標準的 XML Web services，因此當遠程系統是基于 .NET 的平臺或任何其他平臺時，它是最佳選擇。而且 ASP.NET 比 .NET Remoting HTTP 通道的速度快。但 HTTP 通道也有優點，它允許通過引用和真正的異步回調來傳遞參數，這是 ASP.NET 中的 SOAP 支持所不具備的功能。

　　ADO 能夠方便地構建重型客戶端，但客戶端的伸縮性較差，ADO.NET 與 ADO 不同，它更適用于構建輕型客戶端。ADO.NET 客戶端使用僅向前的只讀游標讀取數據。它不支持有狀態的服務器端游標，因此其編程模式鼓勵短時間的連接。直接讀取和處理數據的客戶端可以使用 ADO.NET 的 DataReader 對象，它不為返回的數據提供緩存?；蛘?，可以將數據讀入 DataSet 對象中，將其作為從 SQL 查詢和其他源中返回的數據的緩存。但是，與 ADO 記錄集不同，數據集不能顯式地維護與數據庫的開放連接。

　　如前面所述，ADO 生成的重型方法還存在一些其他問題。這些問題可以在 ADO.NET 中解決，如下所示：

• 對于將數據存儲在數據集并要求訪問由其他用戶或應用程序所做的更改的 ADO.NET 客戶端，需要包含顯式代碼才能進行這些更改。該代碼通常還需要為每個所進行的檢查打開一個數據庫連接。
• 盡管 ADO.NET 并不直接支持保守式鎖定，但通過使用 ADO.NET 事務或在存儲過程中實現所需的功能，客戶端仍然可以獲得同樣的效果。
• 與 ADO 不同，ADO.NET 不允許將部分查詢結果保留在數據庫中（可以使用服務器端游標從中進行訪問）。雖然 ADO.NET 確實比 ADO 檢索的元數據要少，但應用程序仍應設計為能夠將所有的查詢結果從數據庫傳遞到 ADO.NET 客戶端。

　　ADO.NET 中影響體系結構選擇的另一項更改是其對處理分層數據（特別是 XML 文檔）的支持增強了。將 ADO.NET 數據集轉換成 XML 非常簡單，就象訪問 SQL Server 2000 的 XML 功能一樣。因此，在 Windows DNA 中可能被強制裝入關系模型中的分層數據現在可以以其原始形式提供訪問。

　　將數據傳遞到客戶端

　　將數據有效地傳遞到客戶端對于在 .NET 框架上構建的 N 層應用程序和使用 Windows DNA 構建的應用程序同樣重要。一項重要的更改在于，ADO.NET 數據集可自動序列化成 XML，從而使得各層之間的數據傳遞更加簡單。雖然在 Windows DNA 中也可以使用這種方法，但 .NET 使通過 XML 的信息交換變得更加簡單、直接。

　　在構建分布式應用程序的過程中，可以通過多種方法來使用 XML Web services 的 SOAP、Web Services 說明語言 (WSDL) 以及其他技術。例如：

• 使用 SOAP 而不是僅僅使用 HTTP 連接到 N 層應用程序的 Web 客戶端。連接建立后，該客戶端可以是能夠進行 SOAP 調用的任意設備。之后，客戶端可以為其用戶提供更多的功能，因為它能夠直接調用遠程服務器中的方法。
• 將可能是在基于 .NET 框架的平臺上構建的 N 層應用程序與在其他平臺（例如 Java 應用程序服務器）上構建的另一個應用程序連接起來。
• 連接兩個大型應用程序，或者連接一個企業資源規劃 (ERP) 系統與另一個 ERP 系統或任何其他應用程序。正如這些示例所示，XML Web services 不僅僅適用于 N 層應用程序，其應用范圍十分廣闊。

　　不管如何使用，XML Web services 都會帶來許多新的體系結構問題。XML Web services 與 N 層應用程序通常使用的更為傳統的中間件技術之間的最主要的差別或許在于，XML Web services 提供的是“松散耦合”。遺憾的是，這個詞對于不同的用戶有著不同的含義。在本文中，它是指具有以下特點的通信應用程序：

• 應用程序在很大程度上相互獨立，并且通常由不同的組織控制。
• 并不完全可靠。不能保證每個通信應用程序在所有時間都可用。
• 其交互操作可以是同步的，也可以是異步的。Web services 客戶端可能阻塞對某個請求的響應的等待，也可以在發出請求后去做其他事，稍后再來檢查響應。

這些基本特點為使用 XML Web services 的應用程序提供了很多體系結構方面的原則。雖然有些問題可能會在以后的工作中得到解決，如 Microsoft 的 Global XML Web Services Architecture (GXA) specifications（英文），但是目前，創建有效的 XML Web services 應用程序的用戶必須要了解這些問題。其中包括：

• 安全性可能會比較復雜。預先規劃端對端身份驗證和有效授權十分重要。端對端的數據完整性和數據保密性對某些應用程序也很重要?？赡苡斜匾诓煌陌踩珯C制之間進行映射，當然最好盡量避免這種情況?；ゲ僮餍钥赡軙蔀閱栴}。由于規范還相對不成熟，不同供應商的 SOAP 實現還不能始終很好地協作。
• 修改現有應用程序以便可以通過 XML Web services 進行訪問時，可能會出現問題。當把從未打算要在一起使用的程序連接在一起時，總會出現速度、可伸縮性和安全性等問題?，F有應用程序通常不是作為服務器而構建的，因此處理一些很小的請求就會輕易搞垮它們。減少請求數量，而增加每個請求中包含的數據可能會提高應用程序的性能。此外，現有應用程序通常不能處理預料之外的負載，例如向 Internet 公開軟件時可能產生的負載。如果可能，使用某種排隊機制以在請求被響應之前將請求存儲起來，這可能會有所幫助。
• 調節故障非常重要。尤其是只需要一次語義的請求，通常需要格外小心。例如，請求可能會超時，從而觸發重試，但原來的請求可能只是因為某種原因被延遲而已。如果針對單個調用執行兩次遠程 Web service 會出現問題，則必須創建某種機制來解決這個問題。
• 不可能提供依賴于分布式鎖定（跨越組織邊界保持）的端對端事務。大多數組織不允許“外來”應用程序鎖定數據，因此不可能實現兩階段提交樣式的事務。而只能考慮為任何必要的回滾使用補償事務。
• 由于收到的數據可能跨越應用程序和組織邊界，Web services 通信的每一端可能都需要仔細檢查該數據。雖然應用程序的創建者可能十分信任由他們自己的應用程序的其他部分所生成的數據的準確性，但他們不能對其他應用程序抱以同樣的信任。收到的信息甚至可能包含惡意代碼，因此必須仔細檢查。
• SOAP 及其攜帶的 XML 定義的數據非常多。在一個調用中傳遞太多數據可能會搞垮低帶寬的網絡。反過來，在一個調用中傳遞的數據太少又會搞垮處理這些請求的應用程序。盡管這很困難，但找到正確的平衡點還是很重要的。

　　體系結構是關鍵。為應用程序（尤其是分布于多個系統的應用程序）選擇正確的結構是至關重要的。如果選擇了錯誤的體系結構，不管開發人員多么優秀，通常都無法在實現過程中修復。錯誤的決定會導致性能降低、安全性降低以及應用程序需要更新時可用的選項較少。

　　Windows DNA 為 N 層應用程序奠定了一個堅實的基礎，Windows 開發人員可以根據他們從 DNA 領域所學到的知識來構建應用程序，把其中的大部分應用到新的 .NET 環境中。不過，了解本文所建議的更改將有助于創建更快、更安全、功能更強的應用程序。對于 N 層應用程序以及采用 Web services 新技術的應用程序來說，.NET 可提供的功能很多。