將數據傳遞到客戶端

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

　　.net 環境

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

　　將 n 層應用程序與 .net 綁定在一起

　　上一節中介紹的某些問題同樣適用于 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 體系結構

　　在構建分布式應用程序的過程中，可以通過多種方法來使用 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 應用程序的用戶必須要了解這些問題。其中包括：

　　●安全性可能會比較復雜。預先規劃端對端身份驗證和有效授權十分重要。端對端的數據完整性和數據保密性對某些應用程序也很重要。可能有必要在不同的安全機制之間進行映射，當然最好盡量避免這種情況。互操作性可能會成為問題。由于規范還相對不成熟，不同供應商的 soap 實現還不能始終很好地協作。

　　●修改現有應用程序以便可以通過 xml web services 進行訪問時，可能會出現問題。當把從未打算要在一起使用的程序連接在一起時，總會出現速度、可伸縮性和安全性等問題。現有應用程序通常不是作為服務器而構建的，因此處理一些很小的請求就會輕易搞垮它們。減少請求數量，而增加每個請求中包含的數據可能會提高應用程序的性能。此外，現有應用程序通常不能處理預料之外的負載，例如向 internet 公開軟件時可能產生的負載。如果可能，使用某種排隊機制以在請求被響應之前將請求存儲起來，這可能會有所幫助。

　　●調節故障非常重要。尤其是只需要一次語義的請求，通常需要格外小心。例如，請求可能會超時，從而觸發重試，但原來的請求可能只是因為某種原因被延遲而已。如果針對單個調用執行兩次遠程 web service 會出現問題，則必須創建某種機制來解決這個問題。

　　●不可能提供依賴于分布式鎖定(跨越組織邊界保持)的端對端事務。大多數組織不允許“外來”應用程序鎖定數據，因此不可能實現兩階段提交樣式的事務。而只能考慮為任何必要的回滾使用補償事務。

　　●由于收到的數據可能跨越應用程序和組織邊界，web services 通信的每一端可能都需要仔細檢查該數據。雖然應用程序的創建者可能十分信任由他們自己的應用程序的其他部分所生成的數據的準確性，但他們不能對其他應用程序抱以同樣的信任。收到的信息甚至可能包含惡意代碼，因此必須仔細檢查。

　　●soap 及其攜帶的 xml 定義的數據非常多。在一個調用中傳遞太多數據可能會搞垮低帶寬的網絡。反過來，在一個調用中傳遞的數據太少又會搞垮處理這些請求的應用程序。盡管這很困難，但找到正確的平衡點還是很重要的。

　　小結

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

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