三層架構已經學了一段時間,一直想做一個比較完整、比較完美的總結。可是左思右想，不知道怎樣下筆。都說萬事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說到哪吧。
剛開始學習的人非常不理解：
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）之間的數據傳遞（單向）是靠變量或實體作為參數來傳遞的，這樣就構造了三層之間的聯系，完畢了功能的實現。
可是對於大量的數據來說，用變量做參數有些復雜，由於參數量太多，easy搞混。比方：我要把員工信息傳遞到下層，信息包含：員工號、姓名、年齡、性別、工資．．．．用變量做參數的話，那么我們的方法中的參數就會非常多，極有可能在使用時，將參數匹配搞混。這時候，假設用實體做參數，就會非常方便，不用考慮參數匹配的問題，用到實體中哪個屬性拿來直接用就能夠，非常方便。這樣做也提高了效率。
（注：這里為什么說能夠臨時理解為每一個數據表相應一個實體？？答：大家都知道，我們做系統的目的，是為用戶提供服務，用戶可不關心你的系統后台是怎么工作的，用戶僅僅關心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那么數據庫中也要有相應的增、刪、改、查，而增刪改查詳細操作對象就是數據庫中的數據，說白了就是表中的字段。所以，將每一個數據表作為一個實體類，實體類封裝的屬性相應到表中的字段，這種話，實體在貫穿於三層之間時，就能夠實現增刪改查數據了）
綜上所述:三層及實體層之間的依賴關系:
思想來源於生活：
服務員：僅僅管接待客人；
廚師：僅僅管做客人點的菜；
採購員：僅僅管按客人點菜的要求採購食材；
他們各負其職，服務員不用了解廚師怎樣做菜，不用了解採購員怎樣採購食材；廚師不用知道服務員接待了哪位客人，不用知道採購員怎樣採購食材；相同，採購員不用知道服務員接待了哪位客人，不用知道廚師怎樣做菜。
他們三者是怎樣聯系的？
比方：廚師會做：炒茄子、炒雞蛋、炒面——此時構建三個方法（ cookEggplant()、cookEgg()、cookNoodle())
顧客直接和服務員打交道，顧客和服務員（UI層）說：我要一個炒茄子，而服務員不負責炒茄子，她就把請求往上遞交，傳遞給廚師（BLL層），廚師須要茄子，就把請求往上遞交，傳遞給採購員（DAL層），採購員從倉庫里取來茄子傳回給廚師，廚師響應cookEggplant()方法，做好炒茄子后，又傳回給服務員，服務員把茄子呈現給顧客。
這樣就完畢了一個完整的操作。
在此過程中，茄子作為參數在三層中傳遞，假設顧客點炒雞蛋，則雞蛋作為參數（這是變量做參數）。假設，用戶添加需求，我們還得在方法中加入參數，一個方法加入一個，一個方法設計到三層；何況實際中並不止設計到一個方法的更改。所以，為了解決問題，我們能夠把茄子、雞蛋、面條作為屬性定義到顧客實體中，一旦顧客添加了炒雞蛋需求，直接把雞蛋屬性拿出來用就可以，不用再去考慮去每層的方法中加入參數了，更不用考慮參數的匹配問題。
這樣講，不知道大家是不是能夠明確。（待會實例解釋吧）
2，為什么使用三層？
使用三層架構的目的：解耦！！！
相同拿上面飯店的樣例來講：
（1）服務員（UI層）請假——另找服務員；廚師（BLL層）辭職——招聘還有一個廚師；採購員（DAL）辭職——招聘還有一個採購員；
（2）顧客反映：1>你們店服務態度不好——服務員的問題。開除服務員；
2>你們店菜里有蟲子——廚師的問題。換廚師；
不論什么一層發生變化都不會影響到另外一層！！！
3，與兩層的差別？？
兩層：
（當不論什么一個地方發生變化時，都須要又一次開發整個系統。“多層”放在一層，分工不明白耦合度高——難以適應需求變化，可維護性低、可擴展性低）
三層：
（發生在哪一層的變化，僅僅需更改該層，不須要更改整個系統。層次清晰，分工明白，每層之間耦合度低——提高了效率，適應需求變化，可維護性高，可擴展性高）
綜上：三層架構的
優勢：1，結構清晰、耦合度低,2，可維護性高，可擴展性高；3，利於開發任務同步進行；easy適應需求變化
劣勢：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的話，大家觀察一下得須要更改多少地方。這種修改算是小的，假設真的有業務需求上的修改才叫麻煩復雜，程序猿不跳樓才怪。呵呵、、開個玩笑）
與如此難以適應需求變化的兩層相比，大家再次觀察三層代碼，再次思考，三層架構有什么優點呢？自己思考。。。。。
自己去發掘吧！！！