軟件架構模式之分層模式



  分層模式是最通用的架構,也被叫做N層架構模式(n-tier architecture pattern).這也是Java EE應用經常采用的標准模式.基本上都知道它.這種架構模式非常適合傳統的IT通信和組織結構,很自然地成為大部分應用的第一架構選擇。

 

一、模式分析

  分層架構模式里的組件被分成幾個平行的層次,每一層都代表了應用的一個功能(展示邏輯或者業務邏輯)。盡管分層架構沒有規定自身要分成幾層幾種,大多數的結構都分成四個層次:表現層,業務層,持久層,和數據庫層。如圖一,有時候,業務層和持久層會合並成單獨的一個業務層,尤其是持久層的邏輯綁定在業務層的組件當中,形成。因此,有一些小的應用可能只有3層,一些有着更復雜的業務的大應用可能有5層或者更多的分層。

              圖一

  架構里的層次是具體工作的高度抽象,它們每一層都有特定的角色和職能,都是為了實現某種特定的業務請求。比如說展示層並不需要關心怎樣得到用戶數據,它只需在屏幕上以特定的格式展示信息。業務層並不關心要展示在屏幕上的用戶數據格式,也不關心這些用戶數據從哪里來。它只需要從持久層得到數據,執行與數據有關的相應業務邏輯,然后把這些信息傳遞給展示層。各層實現的功能如下:

      表現層(presentation):用戶界面,負責視覺和用戶互動

      業務層(business):實現業務邏輯

      持久層(persistence):提供數據,SQL 語句就放在這一層

      數據庫(database):保存數據

二、關鍵概念——層隔離

  上面圖一中,每一層都是封閉的。這是分層架構中非常重要的特點。這意味request必須一層一層的傳遞。舉個例子,從展示層傳遞來的請求首先會傳遞到業務層,然后傳遞到持久層,最后才傳遞到數據層。

 

圖二

  如果只是獲得以及讀取數據,展示層直接訪問數據層,比穿過一層一層來得到數據來的快多了,那么為什么不允許展示層直接訪問數據層?

  這涉及到一個概念:層隔離。

  層隔離是說架構中的某一層的改變不會影響到其他層:這些變化的影響范圍限於當前層次。如果展示層能夠直接訪問持久層了,假如持久層中的SQL變化了,這對業務層和展示層都有一定的影響。這只會讓應用變得緊耦合,組件之間互相依賴。這種架構會非常的難以維護。分層隔離使得層與層之間都是相互獨立的,架構中的每一層的互相了解都很少。

  然而封閉的架構層次也有不便之處,有時候也應該開放某一層。如果想往包含了一些由業務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子里,新建一個服務層通常是一個好主意,因為從架構上來說,它限制了分享服務訪問業務層(也不允許訪問展示層)。如果沒有隔離層,就沒有任何架構來限制展示層訪問普通服務,難以進行權限管理。

  例如下面的例子,新的服務層是處於業務層之下的,展示層不能直接訪問這個服務層中的組件。但是現在業務層還要通過服務層才能訪問到持久層,這一點也不合理。這是分層架構中的老問題了,解決的辦法是開放某些層。如圖三所示,服務層現在是開放的了。請求可以繞過這一層,直接訪問這一層下面的層。既然服務層是開放的,業務層可以繞過服務層,直接訪問數據持久層。這樣就非常合理。

 

圖三

  開放和封閉層的概念確定了架構層和請求流之間的關系,並且給設計師和開發人員提供了必要的信息理解架構里各種層之間的訪問限制。如果隨意的開放或者封閉架構里的層,整個項目可能都是緊耦合,一團糟的。以后也難以測試,維護和部署。

三、分層架構場景示例

  為了演示分層架構是如何工作的,想象一個場景,如圖四,用戶發出了一個請求要獲得客戶的信息。黑色的箭頭是從數據庫中獲得用戶數據的請求流,紅色箭頭顯示用戶數據的返回流的方向。在這個例子中,用戶信息由客戶數據和訂單數組組成(客戶下的訂單)

  用戶界面只管接受請求以及顯示客戶信息。它不管怎么得到數據的,或者說得到這些數據要用到哪些數據表。如果用戶界面接到了一個查詢客戶信息的請求,它就會轉發這個請求給用戶委托(Customer Delegate)模塊。這個模塊能找到業務層里對應的模塊處理對應數據(約束關系)。業務層里的customer object聚合了業務請求需要的所有信息(在這個例子里獲取客戶信息)。這個模塊調用持久層中的 customer dao 來得到客戶信息,調用order dao來得到訂單信息。這些模塊會執行SQL語句,然后返回相應的數據給業務層。當 customer object收到數據以后,它就會聚合這些數據然后傳遞給 customer delegate,然后傳遞這些數據到customer screen 展示在用戶面前。

圖四

四、分層架構的

優點:

1、開發人員可以只關注整個結構中的其中某一層;

2、可以很容易的用新的實現來替換原有層次的實現;

3、可以降低層與層之間的依賴;

4、有利於標准化;

5、利於各層邏輯的復用。

6、結構更加的明確

7、在后期維護的時候,極大地降低了維護成本和維護時間

缺點

1、降低了系統的性能。這是不言而喻的。如果不采用分層式結構,很多業務可以直接造訪數據庫,以此獲取相應的數據,如今卻必須通過中間層來完成。

2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能,為保證其設計符合分層式結構,可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼。

3、增加了開發成本。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM