軟體架構訓練之層次及使用

在上文中，我介紹了Internet技術，WEB服務在家夠方面給了我們更多的選擇，但軟體設計中採用何種架構仍然是件令人頭痛的事情。

　　兩層系統（圖12）允許使用者介面和應用程式代碼直接存取資料庫和網路儲存的API。應用程式使用資料庫中儲存的資料模型，但是不需要在該模型之上建立邏輯模型。當開發中的系統是一個原型系統或者已經知道其生命週期較短，期間API不會發生變化的時候，兩層應用程式是理想的。典型情形下，這種方式用於小型的應用程式，它們的開發成本和時間都很少。

　　

　　
圖12.兩層架構

　　此外，兩層系統對於面向組件的開發環境也有意義，這種方式用在特定組件的實現之中。組件介面提供了一個隔離層，與這種方式的後果相反。使用指令碼語言建立的多數應用程式都屬於這一類，因為這種情況下多架構層的開發可能非常麻煩，不切實際。

　　最後，兩層的方式將提供更好的效能，並減少控制資源鎖定的機制的需求。儘管兩層模型在處理多個並發使用者使用應用程式方面的能力有些欠缺，但是它的簡單性可能遠遠優於其它的選擇。此外，通過向資料庫應用程式添加通用的資料處理程式，常常能用資料存放區過程來消除一些簡單的共用資料的問題。

　　隨著資料庫的發展，三層（Three-tier）應用程式已經很普通了。三層系統（圖13）滿足了執行的隔離的需求。它基本上對於儲存/資料庫層可能被修改的任何應用系統都是理想的。但是，這種技術的隔離並不僅限於資料庫。它能夠，並且應該用在任何不要求應用程式開發人員，或更重要的應用程式維護人員對於最低層有詳細的瞭解就能共用代碼的環境。

　　

　　

圖13.三層架構

　　相當頻繁的重複使用是一個主要的設計考慮因素，在這種情形下需要建立應用程式模型以允許它的一部分被多個使用者介面查看組件重複使用。它有一個指導方針是，在應用程式需要相同資料的多個視圖的任何時候，開發人員應該考慮使用三層方式代替兩層方式。

　　從兩層模型遷移到三層模型需要考慮的主要問題包括適當的網路資源的可用性和管理並發資料訪問的加鎖方案。

　　作為越來越強調網路計算的結果，最近出現了一種新的趨勢，就是四層系統（圖14）。當應用程式層需要支援進階行為的時候，可以考慮四層系統。四層模型與三層模型相似，但是其應用程式層被分解為表現層和對話層。表現層呈現了應用程式模型的視圖部分，以及被特定視圖的操作所約束的應用程式邏輯。對話層處理表現組件之間的資源共用的問題，包括與潛在的分布式業務物件模型通訊。

　　

當表現組件之間需要大量的協調，並且需要在它們之間共用很多資源的時候就需要四層開發方式。例如，由於效能問題的緣故，緩衝是必要的。對話層允許很多不同的表現組件利用緩衝提供的效能優勢。 同樣，如果某個用戶端被迫作出多個、潛在的複雜的分布式結論，就可以考慮把這種邏輯封裝到應用程式的一個對話層中。

　　很多因素表明考慮四層開發方式的需求為數眾多。很明顯，任何四層系統預期的生命週期很長。已有的組件和子系統的重複使用對於引發與四層系統相關的費用來說通常都是足夠充分的理由。同樣，預計個別組件會頻繁改變設計的目標的環境需要把系統的主要部分與組件實現中的變化隔離開來。四層方式提供了對隨技術的發展（包括傳統的和新的技術）組件和子系統不斷地移植的支援。此外，四層系統比三層系統更容易升級。

　　其它一些考慮因素包括組件的可靠性是未知的或可變的系統。在間歇性的組件失敗中，四層系統可以輕易地合并運行時發現機制（runtime discovery mechanisms）以切換到不同的組件實現上。有四個或多個層次的很多複雜系統最少提供了發現新能力（例如，涉及到新的Web服務實現時，它們就實現了UDDI記錄）的一些能力。如果環境利用了多個、潛在地衝突的技術，四層系統提供了用於管理對話管理層（session management layer）或業務域對象層中的差異的機制。同樣，如果用戶端有多種不同的應用程式模型，而這些模型都需要共用共同的資料資源，那麼四層模型也可能是理想的。經常地，在其它的應用程式組件不希望阻塞並等待資源，不得不在對話層中管理用戶端的訪問的環境中，應用程式組件允許業務域組件處理資源管理的問題並能夠經受得住等待大多數資源。

　　對等（peer-to-peer，P2P）架構方式對於多數需要高度可升級的系統是理想的。同樣，當分布式組件需要協調完成某種事務並且通訊以及其它組件的可靠性可能變化的時候，它們也是有用的。在開發P2P系統的時候作業環境很容易被理解是非常重要的，因為不好的習慣可能導致重大的災難。同樣，當使用P2P技術的時候，介面的標準化和不允許修改也是很重要的。被迫應付多個P2P網路的不相容的版本簡直是個夢魘。

　　N層和/或這些方式的組合（圖15）應該僅僅用於十分複雜的、由多個軟體生命週期不同的子系統和組件構成的系統。這對於大多數大型的不同種類的企業系統是真實的，在這種情況下，在任何時候組件都在升級、更換或添加。對於這種系統，考慮的事項必須通知系統組件的管理部門。

　　

　　

圖15.N層和對等架構的組合

　　哪些特性值得使用複雜的N層系統呢？通常，它包括管理用於增強使用者體驗的大量資料的系統。其需求可能包括記載了使用者的概要資訊、允許使用者佈建參數控制Web頁面和應用程式、管理複雜的安全需求（例如用於控制資源的存取控制清單）、允許使用者要求後端應用程式中的儲存管理和規則執行的進行改變等一些Web網站和應用程式。

　　有了N層應用程式，應用程式的功能被分解為大量的邏輯層，它們可以分開維護和配置。每個層次的功能沒有三層應用程式那麼標準，並且經常把很多層合并成一組來提供表現、應用和/或商務邏輯和儲存管理功能。支援多個層次的主要優點是更容易修改某個層次而不需要改變很多層次（在大多數情形中不需要改變其它任何層次）。此外，通過變更一個或多個層次的分布或載入，應用程式能夠被擴大為處理大量的使用者負載和/或資料。通常這種縮放對於其它層次是透明的，在很多情況下還是自動的。實際上，多層架構被設想為跨多個電腦和處理器分布程式，而不是在某個應用程式中定義軟體的邊界。