目錄

一、什么三層架構？有哪三層？

二、怎樣實作三層架構的聯系

三、舉例

四、為什么使用三層？

五、總結

一、什么三層架構？有哪三層？

三層架構(3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分為：

界面層（User Interface layer）、業務邏輯層（Business Logic Layer）、資料訪問層（Data access layer），

區分層次的目的即為了“高內聚低耦合”的思想，

（高內聚低耦合，是軟體工程中的概念，是判斷設計好壞的標準，主要是面向物件的設計，看類的內聚性是否高，耦合度是否低，）

（內聚關注模塊內部的元素結合程度，耦合關注模塊之間的依賴程度，）

內聚性：又稱塊行內系，指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量，若一個模塊內各元素（語名之間、程式段之間）聯系的越緊密，則它的內聚性就越高，

所謂高內聚是指一個軟體模塊是由相關性很強的代碼組成，只負責一項任務，也就是常說的單一責任原則，

耦合性：也稱塊間聯系，指軟體系統結構中各模塊間相互聯系緊密程度的一種度量，模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差，模塊間耦合高低取決于模塊間介面的復雜性、呼叫的方式及傳遞的資訊，

對于低耦合，粗淺的理解是：一個完整的系統，模塊與模塊之間，盡可能的使其獨立存在，也就是說，讓每個模塊，盡可能的獨立完成某個特定的子功能，模塊與模塊之間的介面，盡量的少而簡單，如果某兩個模塊間的關系比較復雜的話，最好首先考慮進一步的模塊劃分，這樣有利于修改和組合，

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

三層架構分為：表現層（UI）(web層)、業務邏輯層（BLL）(service層)、資料訪問層（DAL）(dao層) ，再加上物體類別庫（Model）

1.UI（表現層），主要是指與用戶互動的界面，用于接收用戶輸入的資料和顯示處理后用戶需要的資料，

2.資料訪問層（DAL），主要是存放對資料類的訪問，即對資料庫的添加、洗掉、修改、更新等基本操作

·DAL就是根據業務需求，構造SQL陳述句，構造引數，呼叫幫助類，獲取結果，DAL層被BIL層呼叫

3.業務邏輯層（BLL），BLL層好比是橋梁，將UI表示層與DAL資料訪問層之間聯系起來，所要負責的，就是處理涉及業務邏輯相關的問題，比如在呼叫訪問資料庫之前，先處理資料、判斷資料，

物體類別庫（Model），在Java中，往往將其稱為Entity物體類，資料庫中用于存放資料，而我們通常選擇會用一個專門的類來抽象出資料表的結構，類的屬性就一對一的對應這表的屬性，

·一般來說，Model物體類別庫層需要被DAL層，BIL層和UI層參考，

三層之間的關系：

二、怎樣實作三層架構的聯系

通過物體層（Enitity）或者說（Model）進行串聯

物體層即是我們對于真實存在事務的抽象，用于編程中進行應用的物件，

Entity(物體層)
它不屬于三層中的任何一層，但是它是必不可少的一層，
Entity在三層架構中的作用：
1、實作面向物件思想中的"封裝";
2、貫穿于三層，在三層之間傳遞資料;（注：確切的說物體層貫穿于三層之間，來連接三層）
3、對于初學者來說，可以這樣理解：每張資料表對應一個物體，即每個資料表中的欄位對應物體中的屬性（注：當然，事實上不是這樣，為什么？1＞，可能我們需要的物體在資料表對應的物體中并不存在；2＞，我們完全可以將所有資料表中的所有欄位都放在一個物體里）
4、每一層（UI—>BLL—>DAL）之間的資料傳遞（單向）是靠變數或物體作為引數來傳遞的，這樣就構造了三層之間的聯系，完成了功能的實作，

但是對于大量的資料來說，用變數做引數有些復雜，因為引數量太多，容易搞混，比如：我要把員工資訊傳遞到下層，資訊包括：員工號、姓名、年齡、性別、工資．．．．用變數做引數的話，那么我們的方法中的引數就會很多，極有可能在使用時，將引數匹配搞混，這時候，如果用物體做引數，就會很方便，不用考慮引數匹配的問題，用到物體中哪個屬性拿來直接用就可以，很方便，這樣做也提高了效率，

（**注：**這里為什么說可以暫時理解為每個資料表對應一個物體？？答：大家都知道，我們做系統的目的，是為用戶提供服務，用戶可不關心你的系統后臺是怎么作業的，用戶只關心軟體是不是好用，界面是不是符合自己心意，用戶在界面上輕松的增、刪、改、查，那么資料庫中也要有相應的增、刪、改、查，而增刪改查具體操作物件就是資料庫中的資料，說白了就是表中的欄位，所以，將每個資料表作為一個物體類，物體類封裝的屬性對應到表中的欄位，這樣的話，物體在貫穿于三層之間時，就可以實作增刪改查資料了）

綜上所述:三層及物體層之間的依賴關系:

三、舉例

一個飯店里，關于服務員、廚師、采購員三者之間的關系

**服務員：** 只管接待客人；

**廚師：** 只管做客人點的菜；

**采購員：** 只管按客人點菜的要求采購食材；

他們各負其職，服務員不用了解廚師如何做菜，不用了解采購員如何采購食材；廚師不用知道服務員接待了哪位客人，不用知道采購員如何采購食材；同樣，采購員不用知道服務員接待了哪位客人，不用知道廚師如何做菜，

他們三者是如何聯系的？

比如：廚師會做：炒茄子、炒雞蛋、炒面——此時構建三個方法（ cookEggplant()、cookEgg()、cookNoodle())，

顧客直接和服務員打交道，顧客和服務員（UI層）說：我要一個炒茄子，而服務員不負責炒茄子，她就把請求往上遞交，傳遞給廚師（BLL層），廚師需要茄子，就把請求往上遞交，傳遞給采購員（DAL層），采購員從倉庫里取來茄子傳回給廚師，廚師回應cookEggplant()方法，做好炒茄子后，又傳回給服務員，服務員把茄子呈現給顧客，

這樣就完成了一個完整的操作，

在此程序中，茄子作為引數在三層中傳遞，如果顧客點炒雞蛋，則雞蛋作為引數（這是變數做引數），如果，用戶增加需求，我們還得在方法中添加引數，一個方法添加一個，一個方法設計到三層；何況實際中并不止設計到一個方法的更改，所以，為了解決這個問題，我們可以把茄子、雞蛋、面條作為屬性定義到顧客物體中，一旦顧客增加了炒雞蛋需求，直接把雞蛋屬性拿出來用即可，不用再去考慮去每層的方法中添加引數了，更不用考慮引數的匹配問題，

四、為什么使用三層？

使用三層架構的目的：解耦！！！（這里又回到了我們最初的目的，為了高內聚低耦合）

同樣拿上面飯店的例子來講：
（1）服務員（UI層）請假——另找服務員；廚師（BLL層）辭職——招聘另一個廚師；采購員（DAL）辭職——招聘另一個采購員；
2）顧客反映：
- 1、你們店服務態度不好——服務員的問題，開除服務員；
- 2、你們店菜里有蟲子——廚師的問題，換廚師；

任何一層發生變化都不會影響到另外一層！！！

三層與兩層的區別：

兩層

（當任何一個地方發生變化時，都需要重新開發整個系統，"多層"放在一層，分工不明確耦合度高——難以適應需求變化，可維護性低、可擴展性低）

三層

（發生在哪一層的變化，只需更改該層，不需要更改整個系統，層次清晰，分工明確，每層之間耦合度低——提高了效率，適應需求變化，可維護性高，可擴展性高）

綜上，三層架構的優勢：
- 1，結構清晰、耦合度低
- 2，可維護性高，可擴展性高
- 3，利于開發任務同步進行, 容易適應需求變化，

說了優勢，那再說說三層架構的劣勢：

- 1，降低了系統的性能，這是不言而喻的，如果不采用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成，
- 2，有時會導致級聯的修改，這種修改尤其體現在自上而下的方向，如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的代碼
- 3，增加了代碼量，增加了作業量

五、總結

但愿離去是幸，我愿永不歸來，

——佛里達