我對于三層架構的了解還不透徹，裝載一篇很好的文章并将我最後的體會寫在最後。
概述
三層架構(3-tierarchitecture) 通常意義上的三層架構就是将整個業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、資料通路層（DAL）。區分層次的目的即為了“高内聚，低耦合”的思想。
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分别為：資料通路層、業務邏輯層（又或稱為領域層）、表示層。
表現層（UI）：通俗講就是展現給使用者的界面，即使用者在使用一個系統的時候他的所見所得。
業務邏輯層（BLL）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。
資料通路層（DAL）：該層所做事務直接操作資料庫，針對資料的增添、删除、修改、查找等。
3個層次中，系統主要功能和業務邏輯都在業務邏輯層進行處理。
所謂三層體系結構，是在用戶端與資料庫之間加入了一個“中間層”，也叫元件層。這裡所說的三層體系，不是指實體上的三層，不是簡單地放置三台機器就是三層體系結構，也不僅僅有B/S應用才是三層體系結構，三層是指邏輯上的三層，即把這三個層放置到一台機器上。
三層體系的應用程式将業務規則、資料通路、合法性校驗等工作放到了中間層進行處理。通常情況下，用戶端不直接與資料庫進行互動，而是通過COM/DCOM通訊與中間層建立連接配接，再經由中間層與資料庫進行互動。
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的話，大家觀察一下得需要更改多少地方。這樣的改動算是小的，如果真的有業務需求上的改動才叫麻煩複雜，程式員不跳樓才怪。呵呵、、開個玩笑）
我嘗試使用簡單的話來描述三層架構。就是需要做到三層之間功能封裝起來，互不幹涉。UI層隻需要調用BLL層的方法，而BLL層直接調用DAL層的方法。而他們之間通過實體來互相傳遞參數。這樣三層機構一個出問題不會影響到另外兩層。