摘要討論 的應用程序設計和所需的更改檢驗從使用 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 環境
將應用程序分解成多個邏輯部分是很有用的將一個大軟件分成幾個小的部分會更利於軟件的構建重復利用和修改對適應不同的技術或不同的業務組織也很有幫助同時還有一些綜合因素需要考慮雖然模塊化和重復使用性很有效但它們可能會導致應用程序不能象使用其他方法那樣安全易管理和快速本節將回顧一些從使用 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？ 的線程操作
●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 域內
●由於 DCOM 需要打開任意端口因此不適合與防火牆配合使用所以對於必須通過 Internet 進行通信的應用程序一般不能使用 DCOM
訪問存儲數據
可以將使用 ADO 構建的數據訪問體系結構分為兩類輕型和重型輕型 ADO 客戶端盡可能簡短地保持數據庫連接並使用存儲過程寫入數據庫輕型客戶端使用以下三種方法之一檢索數據
●通過使用只讀的僅向前游標填充記錄集
●通過存儲過程輸出參數
●使用數據流（在 ADO 的較新版本中）
重型客戶端則會較長時間地保持數據庫連接這類應用程序依賴於開放式連接以及那些連接所允許的有狀態的服務器端游標以
●使記錄集能夠直接訪問其他用戶或應用程序所做的更改
●啟用保守式鎖定
●盡可能減少復制到 ADO 客戶端的數據量以減少網絡通信量與輕型客戶端不同使用服務器端游標的客戶端可以將查詢結果保留在數據庫內直到真正需要這些數據時再取出此外這種方法向記錄集復制的元數據較少而把更多的數據保留在數據庫中
輕型應用程序最具伸縮性因為它們最有效地使用了數據庫連接這一稀有資源相比之下重型應用程序必須保持長期有效的數據庫連接因為這是有狀態的服務器端游標所要求的這就大大地限制了應用程序的可伸縮性尤其不適用於 Internet 服務器應用程序盡管使用 ADO 開發重型應用程序可能更簡單但通常這並不是最佳選擇
ADO 也不是特別適用於處理 XML 文檔等分層數據ADO 完成此項工作的功能用法復雜且不易理解同樣ADO 僅為訪問 SQL Server 的 XML 功能提供有限支持因此Windows DNA 應用程序通常都避免使用 ADO 處理分層數據
將數據傳遞到客戶端
對於所有 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 ASPNET aspx 頁來創建程序集與 ASP 不同在這種情況下完全使用 ASPNET 編寫業務邏輯通常是一個比較好的方法
其中一個原因就是 ASPNET 的內含代碼選項在傳統的 ASP 頁中以一種可維護的方式混合業務代碼和表示代碼並不是一件容易的事而 aspx 頁使用內含代碼能夠完全將這兩種代碼分開Windows DNA 應用程序可能需要同時使用 ASP 頁和 COM 對象才能實現可維護性而使用 NET 框架構建的應用程序則只需使用 ASPNET此外aspx 頁中包含的業務邏輯可以用任何基於 NET 的語言編寫而不僅限於傳統 ASP 頁所支持的簡單的腳本語言而且ASPNET 是編譯頁面而不是解釋頁面因此 ASPNET 應用程序速度可以非常快雖然使用 Windows DNA 構建的應用程序可以使用 ASP 頁和 COM 對象來達到足夠高的性能但 NET 只需使用 ASPNET 便可構建具有同樣優良性能的應用程序最後業務邏輯使用 ASPNET 緩存來減少對包含常用數據的數據庫的訪問這樣可以大大提高性能
但是需要指出的是對於包含在 aspx 頁中的代碼即使是使用內含代碼其重復使用也比標准的程序集困難例如從 Windows 窗體客戶端訪問 aspx 頁中的代碼會遇到很多問題
構建客戶端
使用 NET 框架可減少對 Windows 客戶端的需求通常只需要一個浏覽器客戶端即可其中一個原因在於ASPNET Web 控件允許構建和/或購買可重復使用的浏覽器圖形用戶界面 （GUI） 元素從而能夠更方便地構建更有用的浏覽器客戶端而且可以將基於 NET 框架的組件下載到 Internet Explorer 客戶端然後使用部分信任來運行這些組件（而不使用 ActiveX 控件所要求的全是全非信任模式）這有助於構建更好的用戶界面
管理浏覽器應用程序中的狀態
由於 ASP Session 對象被綁定到一台機器上因此它並未發揮出應有的作用而使用 NET 框架就避免了這種限制與 ASP 不同ASPNET Session 對象可以被兩台或多台機器共享從而可以使用 Session 對象來維護負載平衡的 Web 服務器領域中的狀態使其更加有用而且由於 Session 對象的內容可以選擇存儲在 SQL Server 數據庫中這種機制可用於出現故障時必須一直保持每個客戶端的狀態的應用程序中
影響 ASPNET 應用程序體系結構的另一個重要更改在於數據集可以存儲在 Session 和 Application 對象中而無需包含線程這一點與 ASP 不同也就是說在 Windows DNA 中嚴格規定的不能將記錄集存儲在這些對象中的規則不適用於 NET 框架中的數據集這就使得查詢結果的存儲更加簡單也更加自然
分布式通信
與 Windows DNA 相比NET 框架為應用程序的分布式部件之間的通信提供了更多選擇包括
●NET Remoting提供 TCP 通道和 HTTP 通道
●ASPNET 支持在 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 通道或 ASPNET SOAP 支持
●NET Remoting HTTP 通道和用於 XML Web services 的 ASPNET 支持都能實現 SOAP但這兩種實現卻截然不同各有其特定的目的NET Remoting 注重保持公共語言運行時的確切語義因此當遠程系統也運行 NET 框架時它是最佳選擇ASPNET 則注重提供絕對標准的 XML Web services因此當遠程系統是基於 NET 的平台或任何其他平台時它是最佳選擇而且 ASPNET 比 NET Remoting HTTP 通道的速度快但 HTTP 通道也有優點它允許通過引用和真正的異步回調來傳遞參數這是 ASPNET 中的 SOAP 支持所不具備的功能
訪問存儲數據
ADO 能夠方便地構建重型客戶端但客戶端的伸縮性較差ADONET 與 ADO 不同它更適用於構建輕型客戶端ADONET 客戶端使用僅向前的只讀游標讀取數據它不支持有狀態的服務器端游標因此其編程模式鼓勵短時間的連接直接讀取和處理數據的客戶端可以使用 ADONET 的 DataReader 對象它不為返回的數據提供緩存或者可以將數據讀入 DataSet 對象中將其作為從 SQL 查詢和其他源中返回的數據的緩存但是與 ADO 記錄集不同數據集不能顯式地維護與數據庫的開放連接
如前面所述ADO 生成的重型方法還存在一些其他問題這些問題可以在 ADONET 中解決如下所示
●對於將數據存儲在數據集並要求訪問由其他用戶或應用程序所做的更改的 ADONET 客戶端需要包含顯式代碼才能進行這些更改該代碼通常還需要為每個所進行的檢查打開一個數據庫連接
●盡管 ADONET 並不直接支持保守式鎖定但通過使用 ADONET 事務或在存儲過程中實現所需的功能客戶端仍然可以獲得同樣的效果
●與 ADO 不同ADONET 不允許將部分查詢結果保留在數據庫中（可以使用服務器端游標從中進行訪問）雖然 ADONET 確實比 ADO 檢索的元數據要少但應用程序仍應設計為能夠將所有的查詢結果從數據庫傳遞到 ADONET 客戶端
ADONET 中影響體系結構選擇的另一項更改是其對處理分層數據（特別是 XML 文檔）的支持增強了將 ADONET 數據集轉換成 XML 非常簡單就象訪問 SQL Server 的 XML 功能一樣因此在 Windows DNA 中可能被強制裝入關系模型中的分層數據現在可以以其原始形式提供訪問
將數據傳遞到客戶端
將數據有效地傳遞到客戶端對於在 框架上構建的 N 層應用程序和使用 Windows DNA 構建的應用程序同樣重要一項重要的更改在於ADONET 數據集可自動序列化成 XML從而使得各層之間的數據傳遞更加簡單雖然在 Windows DNA 中也可以使用這種方法但 NET 使通過 XML 的信息交換變得更加簡單直接
XML Web Services 體系結構
在構建分布式應用程序的過程中可以通過多種方法來使用 XML Web services 的 SOAPWeb 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 可提供的功能很多
From:http://tw.wingwit.com/Article/program/net/201311/11733.html
