分層模式是最通用的架構,也被叫作N層架構模式(n-tier architecture pattern).這也是Java EE應用常常採用的標準模式.基本上都知道它.這種架構模式很是適合傳統的IT通訊和組織結構,很天然地成爲大部分應用的第一架構選擇。數據庫
1、模式分析數組
分層架構模式裏的組件被分紅幾個平行的層次，每一層都表明了應用的一個功能(展現邏輯或者業務邏輯)。儘管分層架構沒有規定自身要分紅幾層幾種，大多數的結構都分紅四個層次:表現層，業務層，持久層，和數據庫層。如圖一，有時候，業務層和持久層會合併成單獨的一個業務層，尤爲是持久層的邏輯綁定在業務層的組件當中，造成。所以，有一些小的應用可能只有3層，一些有着更復雜的業務的大應用可能有5層或者更多的分層。架構
圖一性能
架構裏的層次是具體工做的高度抽象，它們每一層都有特定的角色和職能，都是爲了實現某種特定的業務請求。好比說展現層並不須要關心怎樣獲得用戶數據，它只需在屏幕上以特定的格式展現信息。業務層並不關心要展現在屏幕上的用戶數據格式，也不關心這些用戶數據從哪裏來。它只須要從持久層獲得數據，執行與數據有關的相應業務邏輯，而後把這些信息傳遞給展現層。各層實現的功能以下:測試
表現層(presentation):用戶界面,負責視覺和用戶互動spa
業務層(business):實現業務邏輯設計
持久層(persistence):提供數據,SQL 語句就放在這一層blog
數據庫(database):保存數據開發
2、關鍵概念——層隔離部署
上面圖一中，每一層都是封閉的。這是分層架構中很是重要的特色。這意味request必須一層一層的傳遞。舉個例子，從展現層傳遞來的請求首先會傳遞到業務層，而後傳遞到持久層，最後才傳遞到數據層。
圖二
若是隻是得到以及讀取數據，展現層直接訪問數據層，比穿過一層一層來獲得數據來的快多了，那麼爲何不容許展現層直接訪問數據層？
這涉及到一個概念:層隔離。
層隔離是說架構中的某一層的改變不會影響到其餘層:這些變化的影響範圍限於當前層次。若是展現層可以直接訪問持久層了，假如持久層中的SQL變化了，這對業務層和展現層都有必定的影響。這隻會讓應用變得緊耦合，組件之間互相依賴。這種架構會很是的難以維護。分層隔離使得層與層之間都是相互獨立的，架構中的每一層的互相瞭解都不多。
然而封閉的架構層次也有不便之處，有時候也應該開放某一層。若是想往包含了一些由業務層的組件調用的普通服務組件的架構中添加一個分享服務層。在這個例子裏，新建一個服務層一般是一個好主意，由於從架構上來講，它限制了分享服務訪問業務層(也不容許訪問展現層)。若是沒有隔離層，就沒有任何架構來限制展現層訪問普通服務，難以進行權限管理。
例以下面的例子，新的服務層是處於業務層之下的，展現層不能直接訪問這個服務層中的組件。可是如今業務層還要經過服務層才能訪問到持久層，這一點也不合理。這是分層架構中的老問題了，解決的辦法是開放某些層。如圖三所示，服務層如今是開放的了。請求能夠繞過這一層，直接訪問這一層下面的層。既然服務層是開放的，業務層能夠繞過服務層，直接訪問數據持久層。這樣就很是合理。
圖三
開放和封閉層的概念肯定了架構層和請求流之間的關係，而且給設計師和開發人員提供了必要的信息理解架構裏各類層之間的訪問限制。若是隨意的開放或者封閉架構裏的層，整個項目可能都是緊耦合，一團糟的。之後也難以測試，維護和部署。
3、分層架構場景示例
爲了演示分層架構是如何工做的，想象一個場景，如圖四，用戶發出了一個請求要得到客戶的信息。黑色的箭頭是從數據庫中得到用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。
用戶界面只管接受請求以及顯示客戶信息。它無論怎麼獲得數據的，或者說獲得這些數據要用到哪些數據表。若是用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委託(Customer Delegate)模塊。這個模塊能找到業務層裏對應的模塊處理對應數據(約束關係)。業務層裏的customer object聚合了業務請求須要的全部信息(在這個例子裏獲取客戶信息)。這個模塊調用持久層中的 customer dao 來獲得客戶信息，調用order dao來獲得訂單信息。這些模塊會執行SQL語句，而後返回相應的數據給業務層。當 customer object收到數據之後，它就會聚合這些數據而後傳遞給 customer delegate,而後傳遞這些數據到customer screen 展現在用戶面前。
圖四
4、分層架構的優缺點
優勢：
一、開發人員能夠只關注整個結構中的其中某一層；
二、能夠很容易的用新的實現來替換原有層次的實現；
三、能夠下降層與層之間的依賴；
四、有利於標準化；
五、利於各層邏輯的複用。
六、結構更加的明確
七、在後期維護的時候，極大地下降了維護成本和維護時間
缺點
一、下降了系統的性能。這是不言而喻的。若是不採用分層式結構，不少業務能夠直接造訪數據庫，以此獲取相應的數據，現在卻必須經過中間層來完成。
二、有時會致使級聯的修改。這種修改尤爲體如今自上而下的方向。若是在表示層中須要增長一個功能，爲保證其設計符合分層式結構，可能須要在相應的業務邏輯層和數據訪問層中都增長相應的代碼。
三、增長了開發成本。