閱讀835 返回首頁    go 人物


《軟件架構模式》-第一章分層架構(上)

第一章

分層架構

最通常的架構模式就是分層架構模式,即所謂的N層架構。這種模式對大部分JAVAEE應用程序來說是標準模式,因此被大部分架構師、軟件設計師、開發者廣泛知曉。由於分層架構模式和公司裏傳統的IT溝通以及組織結構非常類似,使得它成為大多數商務應用開發最自然的選擇。

模式描述

在分層架構模式中,它將應用分成多個水平層,每個水平層在應用中擔任一個專門的角色(比如表現層或者業務邏輯)。盡管分層架構模型並沒有指定必須的層次個數以及類型,但大部分這種模型都由4個標準層次構成:表現層、業務層、持久層、數據庫(圖1)。在一些情況下,業務層和持久層可以合為一個單一的業務層中,特別是當持久層的邏輯(比如SQL或者HSQL)內嵌於業務層中。因此小應用程序通常隻有三個層‑次,至於更大或者更多的複雜商業應用可能會包含5個或者更多的層次。

在此架構中每層都有一個特定的角色和責任。比如,表現層負責處理所有用戶交互和瀏覽器溝通的邏輯,業務層可能會負責執行和要求相關的特定業務。架構中每層都是每個特定的小作業的抽象,比如表現層必須要或者擔憂怎樣拿到顧客的數據。它隻需要按特定格式顯示信息在屏幕上。而同理業務層也不需要擔憂如果格式化地顯示客戶的數據或者甚至不需要知道客戶數據是從哪裏來。它隻需要從持久層得到數據,基於數據執行業務邏輯(比如計算數值)再把信息上傳給表現層。

這種模型一個強大的特征是隔離開組件按照不同層次。每個層次中的組件隻需要處理屬於那個層次的功能邏輯即可。比如在展示層的組件隻需要處理展示的邏輯,而業務層中的組件隻需要處理業務邏輯。這樣的組件分類方式便於建立高效的角色和責任製的模型,同時也會方便開發、測試、管理、維護應用,因為設計完善的組件接口以及限製的組件功能範圍。

關鍵概念

注意在圖1-2中,架構中的每個層次被標記為封閉狀態。在該架構模式中,這是一個非常重要的概念。一個封閉的層次意味著當需要把消息從一層傳遞給另一層時,它必須先通過位於第一層正下方的那層,才能達到再下麵的一層。例如,一個來自於表現層的要求,必須先通過業務層、持久層才最終到達數據庫。

那麼為什麼不讓表現層直接到達數據庫呢?這樣速度會更快。這裏就牽涉到了一個關鍵概念叫層次分離。

層次分離意味著不同層次間互不影響,你在一個層次上的改動不會影響其他層次。如果你讓表現層能直接訪問持久層,會導致任何在持久層SQL上麵的改動既會影響業務層也會影響表現層,這造成了應用中不同組件之間的強耦合影響,這樣的應用架構也會變得難以修改。

層次分離也意味著不同層次間相對獨立,因此不需要知道另一個層次的內部實現。理解這一點,考慮一個把表現層架構從JSP轉換成JSF的大型重構項目,假設表現層和業務層間的協議不變,那麼業務層不受重構的影響,不會受表現層架構改變的影響。

閉合的層次達成層次分離,會有助於不同層間互不影響,但是也有需要層次開放的時候。例如,假設在一個架構中,有一些需要被業務層次的通用服務組件,因此你想要加一個共享服務層。在種情況,創建一個服務層通常是一個好辦法。因為架構上,它限製了訪問這些共享服務層的必須是業務層而不是表現層。如果沒有一個單獨的服務層,在架構上就不會限製表現層對其的訪問,這樣也會造成管理訪問權限變得困難。

在這個例子中,新服務層位於業務層下,意味著表現層不能直接訪問該層。然後新的問題是,業務層需要穿越新服務層才能到達持久層,這不符合邏輯。實際上,這個問題可以通過設置開放層次解決。

在圖1-3所示,服務層被標誌成開放狀態,意味著業務層允許跨越這層而直接訪問持久層。這在邏輯上是相符的。

借助閉環或者開環層次的概念幫助我們定義架構中層次間的關係以及方向流,同時提供給設計者和開發師必要的信息去理解不同層次的訪問限製。沒有記錄或者沒能和層間合適地溝通通常會導致過緊的耦合以及脆弱的難以測試、維護、部署的架構。

轉載自 並發編程網 - ifeve.com

最後更新:2017-05-18 20:37:06

  上一篇:go  發票識別增值稅發票識別中安未來快人一步
  下一篇:go  Clojure世界:利用HouseMD診斷clojure