在上文中，我介紹了inter***技術
，web服務在家夠方面給了我們更多的選擇，但軟體設計中採用何種架構仍然是件令人頭痛的事情。
兩層系統（圖12）允許使用者介面和應用程式**直接訪問資料庫和網路儲存的api。應用程式使用資料庫中儲存的資料模型，但是不需要在該模型之上建立邏輯模型。當開發中的系統是乙個原型系統或者已經知道其生命週期較短，期間api不會發生變化的時候，兩層應用程式是理想的。典型情形下，這種方式用於小型的應用程式，它們的開發成本和時間都很少。
圖12.兩層架構
此外，兩層系統對於面向元件的開發環境也有意義，這種方式用在特定元件的實現之中。元件介面提供了乙個隔離層，與這種方式的後果相反。使用指令碼語言建立的多數應用程式都屬於這一類，因為這種情況下多架構層的開發可能非常麻煩，不切實際。
最後，兩層的方式將提供更好的效能，並減少控制資源鎖定的機制的需求。儘管兩層模型在處理多個併發使用者使用應用程式方面的能力有些欠缺，但是它的簡單性可能遠遠優於其它的選擇。此外，通過向資料庫應用程式新增通用的資料處理程式，常常能用資料儲存過程來消除一些簡單的共享資料的問題。
隨著資料庫的發展，三層（three-tier）應用程式已經很普通了。三層系統（圖13）滿足了執行的隔離的需求。它基本上對於儲存/資料庫層可能被修改的任何應用系統都是理想的。但是，這種技術的隔離並不僅限於資料庫。它能夠，並且應該用在任何不要求應用程式開發者，或更重要的應用程式維護人員對於最低層有詳細的了解就能共享**的環境。
圖13.三層架構
當表現元件之間需要大量的協調，並且需要在它們之間共享很多資源的時候就需要四層開發方式。例如，由於效能問題的緣故，緩衝是必要的。對話層允許很多不同的表現元件利用緩衝提供的效能優勢。同樣，如果某個客戶端被迫作出多個、潛在的複雜的分布式結論，就可以考慮把這種邏輯封裝到應用程式的乙個對話層中。
很多因素表明考慮四層開發方式的需求為數眾多。很明顯，任何四層系統預期的生命週期很長。已有的元件和子系統的重複使用對於引發與四層系統相關的費用來說通常都是足夠充分的理由。同樣，預計個別元件會頻繁改變設計的目標的環境需要把系統的主要部分與元件實現中的變化隔離開來。四層方式提供了對隨技術的發展（包括傳統的和新的技術）元件和子系統不斷地移植的支援。此外，四層系統比三層系統更容易公升級。
其它一些考慮因素包括元件的可靠性是未知的或可變的系統。在間歇性的元件失敗中，四層系統可以輕易地合併執行時發現機制（runtime discovery mechani**s）以切換到不同的元件實現上。有四個或多個層次的很多複雜系統最少提供了發現新能力（例如，涉及到新的web服務實現時，它們就實現了uddi記錄）的一些能力。如果環境利用了多個、潛在地衝突的技術，四層系統提供了用於管理對話管理層（session management layer）或業務域物件層中的差異的機制。同樣，如果客戶端有多種不同的應用模型，而這些模型都需要共享共同的資料資源，那麼四層模型也可能是理想的。經常地，在其它的應用程式元件不希望阻塞並等待資源，不得不在對話層中管理客戶端的訪問的環境中，應用程式元件允許業務域元件處理資源管理的問題並能夠經受得住等待大多數資源。
對等（peer-to-peer，p2p）架構方式對於多數需要高度可公升級的系統是理想的。同樣，當分布式元件需要協調完成某種事務並且通訊以及其它元件的可靠性可能變化的時候，它們也是有用的。在開發p2p系統的時候操作環境很容易被理解是非常重要的，因為不好的習慣可能導致重大的災難。同樣，當使用p2p技術的時候，介面的標準化和不允許修改也是很重要的。被迫應付多個p2p網路的不相容的版本簡直是個夢魘。
n層和/或這些方式的組合（圖15）應該僅僅用於十分複雜的、由多個軟體生命週期不同的子系統和元件構成的系統。這對於大多數大型的不同種類的企業系統是真實的，在這種情況下，在任何時候元件都在公升級、更換或新增。對於這種系統，考慮的事項必須通知系統元件的管理部門。
圖15.n層和對等架構的組合
哪些特性值得使用複雜的n層系統呢？通常，它包括管理用於增強使用者體驗的大量資料的系統。其需求可能包括記載了使用者的概要資訊、允許使用者設定引數控制web頁面和應用程式、管理複雜的安全需求（例如用於控制資源的訪問控制列表）、允許使用者要求後端應用程式中的儲存管理和規則執行的進行改變等一些web站點和應用程式。
有了n層應用程式，應用程式的功能被分解為大量的邏輯層，它們可以分開維護和配置。每個層次的功能沒有三層應用程式那麼標準，並且經常把很多層合併成一組來提供表現、應用和/或業務邏輯和儲存管理功能。支援多個層次的主要優點是更容易修改某個層次而不需要改變很多層次（在大多數情形中不需要改變其它任何層次）。此外，通過變更乙個或多個層次的分布或載入，應用程式能夠被擴大為處理大量的使用者負載和/或資料。通常這種縮放對於其它層次是透明的，在很多情況下還是自動的。實際上，多層架構被設想為跨多個計算機和處理器分布程式，而不是在某個應用程式中定義軟體的邊界。
基於C 的介面基礎教程 7
第七節 覆蓋虛介面 有時候我們需要表達一種抽象的東西，它是一些東西的概括，但我們又不能真正的看到它成為乙個實體在我們眼前出現，為此物件導向的程式語言便有了抽象類的概念。c 作為乙個物件導向的語言，必然也會引入抽象類這一概念。介面和抽象類使您可以建立元件互動的定義。通過介面，可以指定元件必須實現的方法...
精靈點點基礎教程7 自建窗體
精靈點點簡明教程2 基本操作 精靈點點簡明教程3 錄製指令碼 精靈點點簡明教程4 編輯與除錯指令碼 精靈點點簡明教程5 編寫擴充套件程式 精靈點點簡明教程6 發布指令碼 精靈點點簡明教程7 自建窗體 xml version 1.0 encoding utf 8 window size 300,200...
XSL基礎教程
xsl基礎教程 一 http www 128.ibm.com developerworks cn xml ccidnet xslfund index1.html xsl基礎教程 二 http www.ibm.com developerworks cn xml ccidnet xslfund inde...