三層架構已經學了一段時間,一直想做一個比較完整、比較完美的總結。但是左思右想，不知道如何下筆。都說萬事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說到哪吧。

初學者很不理解：

1，什麼是三層？

2，為什麼使用三層？

3，三層與以往使用的兩層相比有什麼不同？它的優勢在哪裡？

4，如何學好三層？如何應用三層？

……

這篇部落格裡我會給大家一一解釋一下，略懂皮毛忘大家見諒！！！

米老師一直強調：讓學習和生活結合，把學習和生活聯絡，這樣的學習才叫會學習，會生活。

對於三層我左思右想，如何與實際相聯絡。好嘛，昨晚突然有了“靈感”。還記得大話設計模式裡第23章大鳥和小菜吃羊肉串的故事——由在小攤吃到飯店吃引來的一個命令模式（當然今天不是研究命令模式）。服務員、廚師、採購員。

這不就是個典型的三層架構嗎？？？(⊙ o ⊙ )啊！哈哈（這個後面再做解釋）

先了解：

1,什麼是三層？

UI(表現層):主要是指與使用者互動的介面。用於接收使用者輸入的資料和顯示處理後用戶需要的資料。

BLL:(業務邏輯層):UI層和DAL層之間的橋樑。實現業務邏輯。業務邏輯具體包含：驗證、計算、業務規則等等。

DAL:(資料訪問層):與資料庫打交道。主要實現對資料的增、刪、改、查。將儲存在資料庫中的資料提交給業務層，同時將業務層處理的資料儲存到資料庫。（當然這些操作都是基於UI層的。使用者的需求反映給介面（UI），UI反映給BLL，BLL反映給DAL，DAL進行資料的操作，操作後再一一返回，直到將使用者所需資料反饋給使用者）

每一層都各負其責，那麼該如何將三層聯絡起來呢？

1>單項引用（見下圖）

2>這時候實體層（Entity）來了。（注：當然，實體層的作用不止這些）

Entity(實體層)：它不屬於三層中的任何一層，但是它是必不可少的一層。

Entity在三層架構中的作用：

1,實現面向物件思想中的"封裝";

2，貫穿於三層，在三層之間傳遞資料;

（注：確切的說實體層貫穿於三層之間，來連線三層）

3，對於初學者來說，可以這樣理解：每張資料表對應一個實體，即每個資料表中的欄位對應實體中的屬性（注：當然，事實上不是這樣。為什麼？1＞，可能我們需要的實體在資料表對應的實體中並不存在；2＞，我們完全可以將所有資料表中的所有欄位都放在一個實體裡）

4，每一層（UI—>BLL—>DAL）之間的資料傳遞（單向）是靠變數或實體作為引數來傳遞的，這樣就構造了三層之間的聯絡，完成了功能的實現。

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

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

綜上所述:三層及實體層之間的依賴關係:

思想來源於生活：

服務員：只管接待客人；

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

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

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

他們三者是如何聯絡的？

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

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

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

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

這樣講，不知道大家是不是可以明白。（待會例項解釋吧）

2，為什麼使用三層？

使用三層架構的目的：解耦！！！

同樣拿上面飯店的例子來講：

（1）服務員（UI層）請假——另找服務員；廚師（BLL層）辭職——招聘另一個廚師；採購員（DAL）辭職——招聘另一個採購員；

（2）顧客反映：1>你們店服務態度不好——服務員的問題。開除服務員；

2>你們店菜裡有蟲子——廚師的問題。換廚師；

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

3，與兩層的區別？？

兩層：

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

三層：

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

綜上：三層架構的

優勢：1，結構清晰、耦合度低,2，可維護性高，可擴充套件性高；3，利於開發任務同步進行；容易適應需求變化

劣勢：1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。

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

3、增加了程式碼量，增加了工作量

4,三層的具體表現形式？？

UI：

（大家不要誤會，UI層不只是一個個使用者介面，也是需要有程式碼的）

(1,功能：使用者輸入資料、反饋給使用者資料；2,大家觀察程式碼:沒有涉及到業務邏輯，直接傳參、函式、方法呼叫，沒有涉及到與資料庫打交道的SQL語句和ADO.net)

BLL：

（1，BLL是表示層與資料訪問層之間的橋樑，負責資料處理、傳遞；2，大家觀察程式碼，沒有涉及到介面上的控制元件，沒有涉及到SQL語句和ADO.net）

DAL：

(1,以上是DAL層中DbUtil類、user_DA類和workRecord_DA類中的程式碼;2,大家觀察程式碼，沒有涉及到介面控制元件，沒有涉及到業務邏輯；只有與資料庫打交道的SQL語句和ADO.net)

Entity（Model）層：

（定義了實體類user）

觀察以上三層：

1，實體類user作為引數貫穿於三層之間；

2，通過傳參、方法呼叫來實現功能；

3，各層之間各負其責；互不影響

對比兩層結構，讓大家深刻體會三層的極大好處：

還是以機房收費系統的登陸為例：

（觀察上面的兩層的程式碼：將業務邏輯、資料訪問都展現在使用者表現層，當需求需要改變時，需要改變整個系統。比如，我把文字框txtPassWord的名稱改為txtPwd的話，大家觀察一下得需要更改多少地方。這樣的改動算是小的，如果真的有業務需求上的改動才叫麻煩複雜，程式設計師不跳樓才怪。呵呵、、開個玩笑）

與如此難以適應需求變化的兩層相比，大家再次觀察三層程式碼，再次思考，三層架構有什麼好處呢？自己思考。。。。。

自己去發掘吧！！！