三层架构（★）
轉(zhuǎn)載自：http://blog.csdn.net/hanxuemin12345/article/details/8544957
三層架構(gòu)已經(jīng)學了一段時間,一直想做一個比較完整、比較完美的總結(jié)。但是左思右想，不知道如何下筆。都說萬事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說到哪吧。
?
初學者很不理解：
1，什么是三層？
2，為什么使用三層？
3，三層與以往使用的兩層相比有什么不同？它的優(yōu)勢在哪里？
4，如何學好三層？如何應(yīng)用三層？
……
這篇博客里我會給大家一一解釋一下，略懂皮毛忘大家見諒！！！
米老師一直強調(diào)：讓學習和生活結(jié)合，把學習和生活聯(lián)系，這樣的學習才叫會學習，會生活。
對于三層我左思右想，如何與實際相聯(lián)系。好嘛，昨晚突然有了“靈感”。還記得大話設(shè)計模式里第23章大鳥和小菜吃羊肉串的故事——由在小攤吃到飯店吃引來的一個命令模式（當然今天不是研究命令模式）。服務(wù)員、廚師、采購員。
這不就是個典型的三層架構(gòu)嗎？？？(⊙?o?⊙?)啊！哈哈（這個后面再做解釋）
?
?
先了解：
?
1,什么是三層？
UI(表現(xiàn)層):主要是指與用戶交互的界面。用于接收用戶輸入的數(shù)據(jù)和顯示處理后用戶需要的數(shù)據(jù)。
?
BLL:(業(yè)務(wù)邏輯層):UI層和DAL層之間的橋梁。實現(xiàn)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯具體包含：驗證、計算、業(yè)務(wù)規(guī)則等等。
?
DAL:(數(shù)據(jù)訪問層):與數(shù)據(jù)庫打交道。主要實現(xiàn)對數(shù)據(jù)的增、刪、改、查。將存儲在數(shù)據(jù)庫中的數(shù)據(jù)提交給業(yè)務(wù)層，同時將業(yè)務(wù)層處理的數(shù)據(jù)保存到數(shù)據(jù)庫。（當然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進行數(shù)據(jù)的操作，操作后再一一返回，直到將用戶所需數(shù)據(jù)反饋給用戶）
每一層都各負其責，那么該如何將三層聯(lián)系起來呢？
1>單項引用（見下圖）
2>這時候?qū)嶓w層（Entity）來了。（注：當然，實體層的作用不止這些）
?
Entity(實體層)：它不屬于三層中的任何一層，但是它是必不可少的一層。
?
Entity在三層架構(gòu)中的作用：
1,實現(xiàn)面向?qū)ο笏枷胫械?span lang="en-us">"封裝";
2，貫穿于三層，在三層之間傳遞數(shù)據(jù);
（注：確切的說實體層貫穿于三層之間，來連接三層）
3，對于初學者來說，可以這樣理解：每張數(shù)據(jù)表對應(yīng)一個實體，即每個數(shù)據(jù)表中的字段對應(yīng)實體中的屬性（注：當然，事實上不是這樣。為什么？1＞，可能我們需要的實體在數(shù)據(jù)表對應(yīng)的實體中并不存在；2＞，我們完全可以將所有數(shù)據(jù)表中的所有字段都放在一個實體里）
4，每一層（UI—>BLL—>DAL）之間的數(shù)據(jù)傳遞（單向）是靠變量或?qū)嶓w作為參數(shù)來傳遞的，這樣就構(gòu)造了三層之間的聯(lián)系，完成了功能的實現(xiàn)。
但是對于大量的數(shù)據(jù)來說，用變量做參數(shù)有些復(fù)雜，因為參數(shù)量太多，容易搞混。比如：我要把員工信息傳遞到下層，信息包括：員工號、姓名、年齡、性別、工資．．．．用變量做參數(shù)的話，那么我們的方法中的參數(shù)就會很多，極有可能在使用時，將參數(shù)匹配搞混。這時候，如果用實體做參數(shù)，就會很方便，不用考慮參數(shù)匹配的問題，用到實體中哪個屬性拿來直接用就可以，很方便。這樣做也提高了效率。
?
（注：這里為什么說可以暫時理解為每個數(shù)據(jù)表對應(yīng)一個實體？？答：大家都知道，我們做系統(tǒng)的目的，是為用戶提供服務(wù)，用戶可不關(guān)心你的系統(tǒng)后臺是怎么工作的，用戶只關(guān)心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那么數(shù)據(jù)庫中也要有相應(yīng)的增、刪、改、查，而增刪改查具體操作對象就是數(shù)據(jù)庫中的數(shù)據(jù)，說白了就是表中的字段。所以，將每個數(shù)據(jù)表作為一個實體類，實體類封裝的屬性對應(yīng)到表中的字段，這樣的話，實體在貫穿于三層之間時，就可以實現(xiàn)增刪改查數(shù)據(jù)了）
?
綜上所述:三層及實體層之間的依賴關(guān)系:
?
思想來源于生活：
?
?
服務(wù)員：只管接待客人；
廚師：只管做客人點的菜；
采購員：只管按客人點菜的要求采購食材；
?
他們各負其職，服務(wù)員不用了解廚師如何做菜，不用了解采購員如何采購食材；廚師不用知道服務(wù)員接待了哪位客人，不用知道采購員如何采購食材；同樣，采購員不用知道服務(wù)員接待了哪位客人，不用知道廚師如何做菜。
?
他們?nèi)呤侨绾温?lián)系的？
比如：廚師會做：炒茄子、炒雞蛋、炒面——此時構(gòu)建三個方法（cookEggplant()、cookEgg()、cookNoodle())
?
顧客直接和服務(wù)員打交道，顧客和服務(wù)員（UI層）說：我要一個炒茄子，而服務(wù)員不負責炒茄子，她就把請求往上遞交，傳遞給廚師（BLL層），廚師需要茄子，就把請求往上遞交，傳遞給采購員（DAL層），采購員從倉庫里取來茄子傳回給廚師，廚師響應(yīng)cookEggplant()方法，做好炒茄子后，又傳回給服務(wù)員，服務(wù)員把茄子呈現(xiàn)給顧客。
這樣就完成了一個完整的操作。
?
在此過程中，茄子作為參數(shù)在三層中傳遞，如果顧客點炒雞蛋，則雞蛋作為參數(shù)（這是變量做參數(shù)）。如果，用戶增加需求，我們還得在方法中添加參數(shù)，一個方法添加一個，一個方法設(shè)計到三層；何況實際中并不止設(shè)計到一個方法的更改。所以，為了解決這個問題，我們可以把茄子、雞蛋、面條作為屬性定義到顧客實體中，一旦顧客增加了炒雞蛋需求，直接把雞蛋屬性拿出來用即可，不用再去考慮去每層的方法中添加參數(shù)了，更不用考慮參數(shù)的匹配問題。
?
這樣講，不知道大家是不是可以明白。（待會實例解釋吧）
?
2，為什么使用三層？
使用三層架構(gòu)的目的：解耦！！！
同樣拿上面飯店的例子來講：
（1）服務(wù)員（UI層）請假——另找服務(wù)員；廚師（BLL層）辭職——招聘另一個廚師；采購員（DAL）辭職——招聘另一個采購員；
（2）顧客反映：1>你們店服務(wù)態(tài)度不好——服務(wù)員的問題。開除服務(wù)員；
2>你們店菜里有蟲子——廚師的問題。換廚師；
?
任何一層發(fā)生變化都不會影響到另外一層！！！
?
3，與兩層的區(qū)別？？
兩層：
?
（當任何一個地方發(fā)生變化時，都需要重新開發(fā)整個系統(tǒng)。“多層”放在一層，分工不明確耦合度高——難以適應(yīng)需求變化，可維護性低、可擴展性低）
?
三層：
?
?
（發(fā)生在哪一層的變化，只需更改該層，不需要更改整個系統(tǒng)。層次清晰，分工明確，每層之間耦合度低——提高了效率，適應(yīng)需求變化，可維護性高，可擴展性高）
?
綜上：三層架構(gòu)的
優(yōu)勢：1，結(jié)構(gòu)清晰、耦合度低,2，可維護性高，可擴展性高；3，利于開發(fā)任務(wù)同步進行；容易適應(yīng)需求變化
?
劣勢：1、降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。
2、有時會導(dǎo)致級聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼
3、增加了代碼量，增加了工作量
?
4,三層的具體表現(xiàn)形式？？
?
UI：
（大家不要誤會，UI層不只是一個個用戶界面，也是需要有代碼的）
?
(1,功能：用戶輸入數(shù)據(jù)、反饋給用戶數(shù)據(jù)；2,大家觀察代碼:沒有涉及到業(yè)務(wù)邏輯，直接傳參、函數(shù)、方法調(diào)用，沒有涉及到與數(shù)據(jù)庫打交道的SQL語句和ADO.net)
?
BLL：
?
（1，BLL是表示層與數(shù)據(jù)訪問層之間的橋梁，負責數(shù)據(jù)處理、傳遞；2，大家觀察代碼，沒有涉及到界面上的控件，沒有涉及到SQL語句和ADO.net）
?
DAL：
?
?
?
?
(1,以上是DAL層中DbUtil類、user_DA類和workRecord_DA類中的代碼;2,大家觀察代碼，沒有涉及到界面控件，沒有涉及到業(yè)務(wù)邏輯；只有與數(shù)據(jù)庫打交道的SQL語句和ADO.net)
?
Entity（Model）層：
（定義了實體類user）
觀察以上三層：
1，實體類user作為參數(shù)貫穿于三層之間；
2，通過傳參、方法調(diào)用來實現(xiàn)功能；
3，各層之間各負其責；互不影響
?
對比兩層結(jié)構(gòu)，讓大家深刻體會三層的極大好處：
還是以機房收費系統(tǒng)的登陸為例：
（觀察上面的兩層的代碼：將業(yè)務(wù)邏輯、數(shù)據(jù)訪問都展現(xiàn)在用戶表現(xiàn)層，當需求需要改變時，需要改變整個系統(tǒng)。比如，我把文本框txtPassWord的名稱改為txtPwd的話，大家觀察一下得需要更改多少地方。這樣的改動算是小的，如果真的有業(yè)務(wù)需求上的改動才叫麻煩復(fù)雜，程序員不跳樓才怪。呵呵、、開個玩笑）
與如此難以適應(yīng)需求變化的兩層相比，大家再次觀察三層代碼，再次思考，三層架構(gòu)有什么好處呢？自己思考。。。。。
?
自己去發(fā)掘吧！！！
轉(zhuǎn)載于:https://www.cnblogs.com/Edison25/p/8185612.html
總結(jié)
- 上一篇： vim的介绍与常用的命令
- 下一篇： create-react-app部署到G