簡介

　　如今，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 層應用程序的普遍經驗中所獲得的基1咎逑到峁怪丁?

　　編寫業務邏輯

　　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 處理分層數據。