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

2019-11-17 04:43:21

字體：大中小

來源：轉載

供稿：網友

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

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

　　軟件架構練習之層次及使用（圖一）

　　圖12.兩層架構

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

　　最后，兩層的方式將提供更好的性能，并減少控制資源鎖定的機制的需求。盡管兩層模型在處理多個并發用戶使用應用程序方面的能力有些欠缺，但是它的簡單性可能遠遠優于其它的選擇。此外，通過向數據庫應用程序添加通用的數據處理程序，經常能用數據存儲過程來消除一些簡單的共享數據的問題。

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

　　軟件架構練習之層次及使用（圖二）

　　圖13.三層架構

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

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

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

　　軟件架構練習之層次及使用（圖三）

　　圖14.四層架構 QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器
　　當表現組件之間需要大量的協調，并且需要在它們之間共享很多資源的時候就需要四層開發方式。例如，由于性能問題的緣故，緩沖是必要的。對話層答應很多不同的表現組件利用緩沖提供的性能優勢。同樣，假如某個客戶端被迫作出多個、潛在的復雜的分布式結論，就可以考慮把這種邏輯封裝到應用程序的一個對話層中。

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

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

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

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

　　軟件架構練習之層次及使用（圖四）

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

　　哪些特性值得使用復雜的N層系統呢？通常，它包括治理用于增強用戶體驗的大量數據的系統。其需求可能包括記載了用戶的概要信息、答應用戶設置參數控制Web頁面和應用程序、治理復雜的安全需求（例如用于控制資源的訪問控制列表）、答應用戶要求后端應用程序中的存儲治理和規則執行的進行改變等一些Web站點和應用程序。

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

上一篇：嵌入式軟件測試的十大秘訣

下一篇：XAML開發入門之附加屬性和綁定屬性