摘要：討論 Microsoft .NET 的應用程序設計和所需的更改：檢驗從使用 Microsoft Windows DNA 構建 N 層應用程序中學到的結構知識，以及如何將這些知識應用到使用 Microsoft .NET 框架構建的應用程序，并且為使用 xml Web services 的應用程序提供體系結構方面的建議。 簡介 如今，N 層應用程序已經(jīng)成為構建企業(yè)軟件的標準。對于大多數(shù)人來說，N 層應用程序就是被分成多個獨立的邏輯部分的應用程序。最常見的選擇是分為三個部分：表示、業(yè)務邏輯和數(shù)據(jù)，當然還可能存在其他的劃分方法。N 層應用程序最初是為了解決與傳統(tǒng)的客戶端/服務器應用程序相關的問題而出現(xiàn)的，但是，隨著 Web 時代的到來，這一體系結構開始成為新開發(fā)項目的主流。 Microsoft Windows® DNA 技術已成為 N 層應用程序的非常成功的基礎。Microsoft .NET 框架也為構建 N 層應用程序提供了堅實的平臺。然而，.NET 所帶來的變化使結構設計人員應當重新考慮他們在 Windows DNA 領域中所學的有關設計 N 層應用程序的某些知識。更重要的是，對內置于 .NET 框架的 XML Web services 的基本支持答應開發(fā)人員構建突破傳統(tǒng) N 層方法的新應用程序。要了解如何更好地構建 .NET 應用程序的體系結構，您需要了解這一新領域中發(fā)生了哪些變化，以及如何充分利用這些變化。 本文將對這些問題進行討論。首先回顧一下在使用 Windows DNA 構建 N 層應用程序中學到的要害體系結構知識。然后，再按同一順序將這些知識應用到使用 .NET 框架構建應用程序的過程中，從而對它們進行檢驗。最后一部分對使用 XML Web services 的應用程序的體系結構提供了一些建議。 Windows DNA 環(huán)境 將應用程序分解成多個邏輯部分是很有用的。將一個大軟件分成幾個小的部分會更利于軟件的構建、重復利用和修改，對適應不同的技術或不同的業(yè)務組織也很有幫助。同時，還有一些綜合因素需要考慮。雖然模塊化和重復使用性很有效，但它們可能會導致應用程序不能象使用其他方法那樣安全、易治理和快速。本節(jié)將回顧一些從使用 Windows DNA 技術構建 N 層應用程序的普遍經(jīng)驗中所獲得的基本體系結構知識。 編寫業(yè)務邏輯 Windows DNA 應用程序通常使用以下三種實現(xiàn)方式中的一種或多種方式來實現(xiàn)其業(yè)務邏輯：
一般來講，在 ASP 頁中編寫過多的業(yè)務邏輯并不是一個好辦法。因為必須使用簡單的語言，例如 Microsoft Visual Basic® Script (VBScript)，而且每次執(zhí)行時都要解釋代碼，這會對性能造成影響。而且 ASP 頁中的代碼不好維護，主要是因為業(yè)務邏輯通常與創(chuàng)建用戶界面的表示代碼混合在一起。 鑒于這種情況，建議在編寫中間層業(yè)務邏輯時，將業(yè)務邏輯當作 COM 對象來實現(xiàn)。這種方法比編寫純粹的 ASP 應用程序要稍微復雜一點，但是可以使用全功能語言來生成編譯好的可執(zhí)行文件，因此其結果要快得多。將業(yè)務邏輯包裝在 COM 對象中還可以將此代碼與包含在 ASP 頁中的表示代碼完全分隔開來，從而使應用程序更易于維護。 從 COM 到 COM+，其體系結構相差無幾。但是，正如許多 Windows DNA 體系結構設計人員所了解的，除非真正需要，否則不應使用 COM+ 提供的核心服務，如事務、實時 (JIT) 激活、基于角色的安全性和線程服務等。使用其他開發(fā)平臺提供的 COM+ 或類似服務自然會導致應用程序速度更慢、更復雜。只有在以下情況下使用 COM+ 才有意義：
需要跨越不同資源治理器（如 Microsoft SQL Server™ 和 Oracle）的分布式事務。
應用程序可以有效地利用基于角色的安全性。
可以增強 Microsoft Visual Basic® 6.0 的線程操作。
JIT 激活能夠提高性能；瀏覽器客戶端很少出現(xiàn)這種情況，因為 ASP 頁是通過 JIT 有效激活的。
COM+ 的配置優(yōu)勢大大簡化了應用程序的部署。
編寫業(yè)務邏輯的第三種方式是，創(chuàng)建一些作為存儲過程在數(shù)據(jù)庫治理系統(tǒng) (DBMS) 中運行的代碼。盡管使用存儲過程的主要原因是將數(shù)據(jù)庫架構的具體信息與業(yè)務邏輯分隔開以簡化代碼的治理和提高安全性，但代碼與數(shù)據(jù)如此接近也有助于優(yōu)化性能。那些必須獨立于 DBMS 的應用程序（例如由獨立的軟件供給商創(chuàng)建的應用程序）通常要避免使用這種方法，因為它會將應用程序鎖定到某個特定的數(shù)據(jù)庫系統(tǒng)中。存儲過程的編寫和調試可能會比 COM 對象的編寫和調試難，而且此方法會減少重復使用代碼的機會，這是因為 COM 對象通常比存儲過程更易于重復使用。但是大多數(shù)自定義應用程序仍然連接到最初創(chuàng)建它們的 DBMS 上，因此使用存儲過程的性能優(yōu)勢還是很大的。鑒于這種情況，那些必須盡可能運行良好的 Windows DNA 應用程序通常對部分或全部的業(yè)務邏輯都使用存儲過程。 構建客戶端 Windows DNA 既支持用 Visual Basic 等語言編寫的本地 Windows 客戶端，也支持瀏覽器客戶端。瀏覽器客戶端的局限性較大，尤其同時將 Microsoft Internet EXPlorer 和 Netscape 作為瀏覽器時。 因此，應用程序通常同時擁有瀏覽器客戶端和本地 Windows 客戶端。瀏覽器客戶端提供的界面很有限，但用它可以方便地訪問 Internet，而 Windows 客戶端能提供全功能的界面。使用可下載的 Microsoft ActiveX® 控件可以創(chuàng)建更復雜的瀏覽器界面，但必須確保瀏覽器是 Internet Explorer，并且用戶愿意信任應用程序的創(chuàng)建者。 治理瀏覽器應用程序中的狀態(tài) ASP 應用程序可以使用幾個不同的機制來維護服務器上客戶端請求之間的信息。但是 Windows DNA 中有一條嚴格的規(guī)則，假如應用程序在兩臺或多臺機器之間平衡負載，則絕對不能使用 ASP session 對象存儲每個客戶端的狀態(tài)。ASP 的 Session 對象被鎖定在一臺機器上，因此不能用于負載平衡的應用程序。 ASP Session 對象和 ASP application 對象還有另一個限制。使用它們中的任何一個來存儲 ADO 記錄集都會大大降低可伸縮性，因為它限制了應用程序開發(fā)多線程的能力。因此，在這兩個對象的任何一個中存儲記錄集都不是好辦法。 分布式通信 在 Windows DNA 中，選擇運行在不同機器上的組件的通信方式非常簡單：DCOM 可以說是唯一的選擇。單純從體系結構上來看，DCOM 是 COM 的簡單擴展。但實際上，DCOM 還有許多其他含義，其中包括：
由于實際上是其自有協(xié)議，因而使用 DCOM 與遠程 COM+ 對象進行通信非常直接。
只要配置正確，DCOM 將是非常安全的協(xié)議。但是要實現(xiàn)這種配置并不輕易，因此該協(xié)議不太輕易使用。盡管如此，DCOM 自身仍能提供很好的分布式身份驗證、數(shù)據(jù)完整性和數(shù)據(jù)保密性，非凡是在 windows 2000 域內。
由于 DCOM 需要打開任意端口，因此不適合與防火墻配合使用。所以，對于必須通過 Internet 進行通信的應用程序，一般不能使用 DCOM。
輕型應用程序最具伸縮性，因為它們最有效地使用了數(shù)據(jù)庫連接這一稀有資源。相比之下，重型應用程序必須保持長期有效的數(shù)據(jù)庫連接，因為這是有狀態(tài)的服務器端游標所要求的。這就大大地限制了應用程序的可伸縮性，尤其不適用于 Internet 服務器應用程序。盡管使用 ADO 開發(fā)重型應用程序可能更簡單，但通常這并不是最佳選擇。 ADO 也不是非凡適用于處理 XML 文檔等分層數(shù)據(jù)。ADO 完成此項工作的功能用法復雜，且不易理解。同樣，ADO 僅為訪問 SQL Server 2000 的 XML 功能提供有限支持，因此，Windows DNA 應用程序通常都避免使用 ADO 處理分層數(shù)據(jù)。 將數(shù)據(jù)傳遞到客戶端 對于所有 N 層應用程序而言，將數(shù)據(jù)從中間層有效地移動到客戶端都是一個要害的環(huán)節(jié)。當使用 DCOM 與 Windows 客戶端通信時，Windows DNA 應用程序可以使用 ADO 斷開連接的記錄集。 當確保瀏覽器為 Internet Explorer 時，此選項也可用于瀏覽器客戶端。而將數(shù)據(jù)發(fā)送到任意瀏覽器則比較困難。一種方法是顯式地將數(shù)據(jù)轉換為 XML，然后將數(shù)據(jù)和所有必要的腳本代碼發(fā)送到瀏覽器。 .NET 環(huán)境 .NET 支持傳統(tǒng)的 N 層應用程序、Web services 應用程序以及將二者的元素結合在一起的應用程序。本節(jié)首先介紹 .NET 如何影響 N 層應用程序，然后介紹構建 Web services 應用程序過程中的幾個主要的體系結構問題。 將 N 層應用程序與 .NET 綁定在一起 上一節(jié)中介紹的某些問題同樣適用于 Windows DNA 應用程序和使用 .NET 框架構建的應用程序。例如，只有當滿足前面所列的一個或多個條件時，才能使用 COM+（在 .NET 框架中稱為企業(yè)服務）。同樣，將業(yè)務邏輯構建為存儲過程在很多 N 層應用程序中都可以獲得更好的性能。 同時，.NET 框架中到處都是新技術和現(xiàn)有技術的新版本。這些增強功能為 N 層應用程序的優(yōu)化體系結構帶來了多種變化。本節(jié)將按照前面介紹的分類，介紹 .NET 框架是如何改變體系結構設計人員在創(chuàng)建 N 層應用程序時所做的決定的。 編寫業(yè)務邏輯 與在 Windows DNA 中創(chuàng)建 N 層業(yè)務邏輯的三種可選方法（ASP 頁、COM 組件和存儲過程）不同，.NET 框架只提供了兩種方法：程序集和存儲過程。對于瀏覽器應用程序，可以使用 Microsoft asp.net .aspx 頁來創(chuàng)建程序集。與 ASP 不同，在這種情況下完全使用 ASP.NET 編寫業(yè)務邏輯通常是一個比較好的方法。 其中一個原因就是 ASP.NET 的內含代碼選項。在傳統(tǒng)的 ASP 頁中，以一種可維護的方式混合業(yè)務代碼和表示代碼并不是一件輕易的事，而 .aspx 頁使用內含代碼能夠完全將這兩種代碼分開。Windows DNA 應用程序可能需要同時使用 ASP 頁和 COM 對象才能實現(xiàn)可維護性，而使用 .NET 框架構建的應用程序則只需使用 ASP.NET。此外，.aspx 頁中包含的業(yè)務邏輯可以用任何基于 .NET 的語言編寫，而不僅限于傳統(tǒng) ASP 頁所支持的簡單的腳本語言。而且，ASP.NET 是編譯頁面而不是解釋頁面，因此 ASP.NET 應用程序速度可以非常快。雖然使用 Windows DNA 構建的應用程序可以使用 ASP 頁和 COM 對象來達到足夠高的性能，但 .NET 只需使用 ASP.NET 便可構建具有同樣優(yōu)良性能的應用程序。最后，業(yè)務邏輯使用 ASP.NET 緩存來減少對包含常用數(shù)據(jù)的數(shù)據(jù)庫的訪問，這樣可以大大提高性能。 但是，需要指出的是，對于包含在 .aspx 頁中的代碼，即使是使用內含代碼，其重復使用也比標準的程序集困難。例如，從 Windows 窗體客戶端訪問 .aspx 頁中的代碼會碰到很多問題。 構建客戶端 使用 .NET 框架可減少對 Windows 客戶端的需求，通常只需要一個瀏覽器客戶端即可。其中一個原因在于，ASP.NET Web 控件答應構建和/或購買可重復使用的瀏覽器圖形用戶界面 (GUI) 元素，從而能夠更方便地構建更有用的瀏覽器客戶端。而且可以將基于 .NET 框架的組件下載到 Internet Explorer 客戶端，然后使用部分信任來運行這些組件（而不使用 ActiveX 控件所要求的全是全非信任模式），這有助于構建更好的用戶界面。 治理瀏覽器應用程序中的狀態(tài) 由于 ASP Session 對象被綁定到一臺機器上，因此它并未發(fā)揮出應有的作用，而使用 .NET 框架就避免了這種限制。與 ASP 不同，ASP.NET Session 對象可以被兩臺或多臺機器共享，從而可以使用 Session 對象來維護負載平衡的 Web 服務器領域中的狀態(tài)，使其更加有用。而且，由于 Session 對象的內容可以選擇存儲在 SQL Server 數(shù)據(jù)庫中，這種機制可用于出現(xiàn)故障時必須一直保持每個客戶端的狀態(tài)的應用程序中。 影響 ASP.NET 應用程序體系結構的另一個重要更改在于，數(shù)據(jù)集可以存儲在 Session 和 Application 對象中而無需包含線程，這一點與 ASP 不同。也就是說，在 Windows DNA 中嚴格規(guī)定的不能將記錄集存儲在這些對象中的規(guī)則不適用于 .NET 框架中的數(shù)據(jù)集。這就使得查詢結果的存儲更加簡單也更加自然。 分布式通信 與 Windows DNA 相比，.NET 框架為應用程序的分布式部件之間的通信提供了更多選擇，包括：
.NET Remoting，提供 TCP 通道和 HTTP 通道；
ASP.NET 支持在 .asmx 頁中實現(xiàn)的、可通過 SOAP 調用的 XML Web services；
DCOM 不能很好地與防火墻配合使用，.NET Remoting HTTP 通道與之不同，它是專門為在 Internet 上進行有效通信而設計的。而且，由于可以使用 SSL，此選項能夠為數(shù)據(jù)提供安全的路徑。通常，對于 Intranet 通信而言，TCP 通道是較好的選擇；而對于 Internet 通信，則更適合使用 HTTP 通道或 ASP.NET SOAP 支持。
.NET Remoting HTTP 通道和用于 XML Web services 的 ASP.NET 支持都能實現(xiàn) SOAP。但這兩種實現(xiàn)卻截然不同，各有其特定的目的。.NET Remoting 注重保持公共語言運行時的確切語義，因此當遠程系統(tǒng)也運行 .NET 框架時，它是最佳選擇。ASP.NET 則注重提供絕對標準的 XML Web services，因此當遠程系統(tǒng)是基于 .NET 的平臺或任何其他平臺時，它是最佳選擇。而且 ASP.NET 比 .NET Remoting HTTP 通道的速度快。但 HTTP 通道也有優(yōu)點，它答應通過引用和真正的異步回調來傳遞參數(shù)，這是 ASP.NET 中的 SOAP 支持所不具備的功能。
ADO.NET 中影響體系結構選擇的另一項更改是其對處理分層數(shù)據(jù)（非凡是 XML 文檔）的支持增強了。將 ADO.NET 數(shù)據(jù)集轉換成 XML 非常簡單，就象訪問 SQL Server 2000 的 XML 功能一樣。因此，在 Windows DNA 中可能被強制裝入關系模型中的分層數(shù)據(jù)現(xiàn)在可以以其原始形式提供訪問。 將數(shù)據(jù)傳遞到客戶端 將數(shù)據(jù)有效地傳遞到客戶端對于在 .NET 框架上構建的 N 層應用程序和使用 Windows DNA 構建的應用程序同樣重要。一項重要的更改在于，ADO.NET 數(shù)據(jù)集可自動序列化成 XML，從而使得各層之間的數(shù)據(jù)傳遞更加簡單。雖然在 Windows DNA 中也可以使用這種方法，但 .NET 使通過 XML 的信息交換變得更加簡單、直接。 XML Web Services 體系結構 在構建分布式應用程序的過程中，可以通過多種方法來使用 XML Web services 的 SOAP、Web Services 說明語言 (WSDL) 以及其他技術。例如：
使用 SOAP 而不是僅僅使用 HTTP 連接到 N 層應用程序的 Web 客戶端。連接建立后，該客戶端可以是能夠進行 SOAP 調用的任意設備。之后，客戶端可以為其用戶提供更多的功能，因為它能夠直接調用遠程服務器中的方法。
將可能是在基于 .NET 框架的平臺上構建的 N 層應用程序與在其他平臺（例如 java 應用程序服務器）上構建的另一個應用程序連接起來。
連接兩個大型應用程序，或者連接一個企業(yè)資源規(guī)劃 (ERP) 系統(tǒng)與另一個 ERP 系統(tǒng)或任何其他應用程序。正如這些示例所示，XML Web services 不僅僅適用于 N 層應用程序，其應用范圍十分廣闊。
不管如何使用，XML Web services 都會帶來許多新的體系結構問題。XML Web services 與 N 層應用程序通常使用的更為傳統(tǒng)的中間件技術之間的最主要的差別或許在于，XML Web services 提供的是“松散耦合”。遺憾的是，這個詞對于不同的用戶有著不同的含義。在本文中，它是指具有以下特點的通信應用程序：
這些基本特點為使用 XML Web services 的應用程序提供了很多體系結構方面的原則。雖然有些問題可能會在以后的工作中得到解決，如 Microsoft 的 Global XML Web Services Architecture (GXA) specifications（英文），但是目前，創(chuàng)建有效的 XML Web services 應用程序的用戶必須要了解這些問題。其中包括：
修改現(xiàn)有應用程序以便可以通過 XML Web services 進行訪問時，可能會出現(xiàn)問題。當把從未打算要在一起使用的程序連接在一起時，總會出現(xiàn)速度、可伸縮性和安全性等問題。現(xiàn)有應用程序通常不是作為服務器而構建的，因此處理一些很小的請求就會輕易搞垮它們。減少請求數(shù)量，而增加每個請求中包含的數(shù)據(jù)可能會提高應用程序的性能。此外，現(xiàn)有應用程序通常不能處理預料之外的負載，例如向 Internet 公開軟件時可能產(chǎn)生的負載。假如可能，使用某種排隊機制以在請求被響應之前將請求存儲起來，這可能會有所幫助。
調節(jié)故障非常重要。尤其是只需要一次語義的請求，通常需要格外小心。例如，請求可能會超時，從而觸發(fā)重試，但原來的請求可能只是因為某種原因被延遲而已。假如針對單個調用執(zhí)行兩次遠程 Web service 會出現(xiàn)問題，則必須創(chuàng)建某種機制來解決這個問題。
SOAP 及其攜帶的 XML 定義的數(shù)據(jù)非常多。在一個調用中傳遞太多數(shù)據(jù)可能會搞垮低帶寬的網(wǎng)絡。反過來，在一個調用中傳遞的數(shù)據(jù)太少又會搞垮處理這些請求的應用程序。盡管這很困難，但找到正確的平衡點還是很重要的。
小結 體系結構是要害。為應用程序（尤其是分布于多個系統(tǒng)的應用程序）選擇正確的結構是至關重要的。假如選擇了錯誤的體系結構，不管開發(fā)人員多么優(yōu)秀，通常都無法在實現(xiàn)過程中修復。錯誤的決定會導致性能降低、安全性降低以及應用程序需要更新時可用的選項較少。 Windows DNA 為 N 層應用程序奠定了一個堅實的基礎，Windows 開發(fā)人員可以根據(jù)他們從 DNA 領域所學到的知識來構建應用程序，把其中的大部分應用到新的 .NET 環(huán)境中。不過，了解本文所建議的更改將有助于創(chuàng)建更快、更安全、功能更強的應用程序。對于 N 層應用程序以及采用 Web services 新技術的應用程序來說，.NET 可提供的功能很多。
