三層架構分析

三層通常分爲兩類：物理上的三層和邏輯上的三層架構；物理三層架構是以邏輯的三層架構爲基礎的，假設沒有了邏輯的三層。就根本談不上物理三層架構的部署。

    什麼是物理三層架構呢？

    從簡單了說就是每一層都分別作成一個組件。如業務邏輯組件，業務實體組件，數據訪問組件等。在到複雜一些就是構建分佈式系統，好比將業務邏輯層與數據訪問分別部署在不一樣的server上。

咱們這裏講的主要是邏輯上的三層架構。

三層基礎知識

在軟件體系架構設計中，分層式結構是最多見，也是最重要的一種結構。

微軟推薦的分層式結構通常分爲三層，從下至上分別爲：數據訪問層、業務邏輯層（又或稱爲領域層）、表示層。

那麼每層都有什麼做用呢。見下表：

	做用	設計原則	常用技術
表示層(UI)	向用戶展示特定業務數據，採集用戶的輸入信息和操做	用戶至上。兼顧簡潔；不包括不論什麼業務相關的邏輯處理	WindowsＦｏｒｍ＼ＡＳＰ.ＮＥＴ
業務邏輯層(BLL)	從ＤＡＬ中獲取數據，在ＵＩ顯示；從ＵＩ中獲取用戶指令和數據。運行業務邏輯或經過ＤＡＬ寫入數據源。	做爲U層與Ｄ層的橋樑，僅僅負責數據處理傳遞，不涉及ＳＱＬ語句和ＡＤＯ.ＮＥＴ	——————————————
數據訪問層(DAL)	直接操做數據庫，針對數據的增添、刪除、改動、查找；詳細爲業務邏輯層或表示層提供數據服務。	僅僅提供主要的數據訪問。不包括不論什麼業務邏輯處理。	ＡＤＯ.ＮＥＴ＋ＳＱＬ語句；ＯＲＭ框架；Ｌｉｎｑ　Ｔｏ　ＳＱＬ

 

三層結構圖：

 

    說到三層，你們是否是想知道有沒有兩層結構。答案是有！而且就在咱們身邊．曾經咱們的做品展，信息管理系統，第一遍機房收費。都是典型兩層結構。

   兩層結構圖：

 

          

 

從圖中就可以看出，兩層結構把界面。邏輯和數據訪問通通放在了一塊兒，互相糾纏．致使了高耦合。難複用而且當需求變動時所面臨的很是多是又一次開發．固然更別說後期的維護問題了。

 

相比於兩層架構而言。三層有很是多優點：

一、開發者可以僅僅關注整個結構中的當中某一層；

二、可以很是easy的用新的實現來替換原有層次的實現；

三、可以減小層與層之間的依賴。

四、有利於標準化；

五、利於各層邏輯的複用。

六、結構更加的明白

七、在後期維護的時候。極大地減小了維護成本和維護時間

 

固然有這麼多的優點，並不意味着所有的程序都需要應用三層架構，一些簡單的小程序的編寫全然不是必需這麼複雜，而一些真正複雜的項目，三層有時候不夠用，需要多層結構。

 

金無足赤。和設計模式同樣，三層架構也有他的一些小缺點：

一、減小了系統的性能。這是不言而喻的。假設不採用分層式結構，很是多業務可以直接造訪數據庫，以此獲取對應的數據，如今卻必須經過中間層來完畢。

二、有時會致使級聯的改動。這樣的改動尤爲體現在自上而下的方向。假設在表示層中需要添加一個功能，爲保證其設計符合分層式結構，可能需要在對應的業務邏輯層和數據訪問層中都添加對應的代碼。

三、添加了開發成本。

基礎的知識就講到這，咱們能不能從生活中找到三層的影子呢？

       我想起了有次暑假打工的經歷，那是在一家酒店作的廚師助理。呵呵。這麼好聽的名字。說白了就是打雜的，所作的工做就是：從倉庫中幫廚師找到作某道菜需要的食材。配料等。

酒店的服務工做流程是這種，服務員負責接待顧客，顧客經過菜單點了某些菜，服務員將顧客點的菜單提交給廚師。而後依據菜單所需。轉告廚師助理去提取對應的原料，而後廚師將這些原料製做成美味的佳餚轉交給服務員，服務員再將佳餚交給顧客。顧客在享用這些美味。

是否是有種很是熟悉的感受，服務員，廚師，助理　不正是很是好的解釋了三層架構嗎？

服務員（表示層）：負責前臺的工做與顧客（客戶）打交道。

廚師（業務邏輯層）：負責詳細製做某些菜（邏輯處理）

助理（數據訪問）：負責從倉庫（數據庫）中尋找某些食材配料（數據）

 知識來源於生活，聯繫生活來學習更有助於理解。

學了設計模式和三層才知道，做品展、學生系統、第一遍機房收費系統等都是在搭雞窩，所有的代碼都放在一個個窗口裏面，而且窗口間耦合還巨強，汗。。