版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接和本聲明。
本文鏈接：https://blog.csdn.net/hanxuemin12345/article/details/8544957

三層架構(gòu)已經(jīng)學(xué)了一段時(shí)間,一直想做一個(gè)比較完整、比較完美的總結(jié)。但是左思右想，不知道如何下筆。都說(shuō)萬(wàn)事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說(shuō)到哪吧。

初學(xué)者很不理解：

1，什么是三層？

2，為什么使用三層？

3，三層與以往使用的兩層相比有什么不同？它的優(yōu)勢(shì)在哪里？

4，如何學(xué)好三層？如何應(yīng)用三層？

……

這篇博客里我會(huì)給大家一一解釋一下，略懂皮毛忘大家見諒！！！

米老師一直強(qiáng)調(diào)：讓學(xué)習(xí)和生活結(jié)合，把學(xué)習(xí)和生活聯(lián)系，這樣的學(xué)習(xí)才叫會(huì)學(xué)習(xí)，會(huì)生活。

對(duì)于三層我左思右想，如何與實(shí)際相聯(lián)系。好嘛，昨晚突然有了“靈感”。還記得大話設(shè)計(jì)模式里第23章大鳥和小菜吃羊肉串的故事——由在小攤吃到飯店吃引來(lái)的一個(gè)命令模式（當(dāng)然今天不是研究命令模式）。服務(wù)員、廚師、采購(gòu)員。

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

先了解：

1,什么是三層？

UI(表現(xiàn)層):主要是指與用戶交互的界面。用于接收用戶輸入的數(shù)據(jù)和顯示處理后用戶需要的數(shù)據(jù)。

BLL:(業(yè)務(wù)邏輯層):UI層和DAL層之間的橋梁。實(shí)現(xiàn)業(yè)務(wù)邏輯。業(yè)務(wù)邏輯具體包含：驗(yàn)證、計(jì)算、業(yè)務(wù)規(guī)則等等。

DAL:(數(shù)據(jù)訪問層):與數(shù)據(jù)庫(kù)打交道。主要實(shí)現(xiàn)對(duì)數(shù)據(jù)的增、刪、改、查。將存儲(chǔ)在數(shù)據(jù)庫(kù)中的數(shù)據(jù)提交給業(yè)務(wù)層，同時(shí)將業(yè)務(wù)層處理的數(shù)據(jù)保存到數(shù)據(jù)庫(kù)。（當(dāng)然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進(jìn)行數(shù)據(jù)的操作，操作后再一一返回，直到將用戶所需數(shù)據(jù)反饋給用戶）

每一層都各負(fù)其責(zé)，那么該如何將三層聯(lián)系起來(lái)呢？

1>單項(xiàng)引用（見下圖）

2>這時(shí)候?qū)嶓w層（Entity）來(lái)了。（注：當(dāng)然，實(shí)體層的作用不止這些）

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

Entity在三層架構(gòu)中的作用：

1,實(shí)現(xiàn)面向?qū)ο笏枷胫械?封裝";

2，貫穿于三層，在三層之間傳遞數(shù)據(jù);

（注：確切的說(shuō)實(shí)體層貫穿于三層之間，來(lái)連接三層）

3，對(duì)于初學(xué)者來(lái)說(shuō)，可以這樣理解：每張數(shù)據(jù)表對(duì)應(yīng)一個(gè)實(shí)體，即每個(gè)數(shù)據(jù)表中的字段對(duì)應(yīng)實(shí)體中的屬性（注：當(dāng)然，事實(shí)上不是這樣。為什么？1＞，可能我們需要的實(shí)體在數(shù)據(jù)表對(duì)應(yīng)的實(shí)體中并不存在；2＞，我們完全可以將所有數(shù)據(jù)表中的所有字段都放在一個(gè)實(shí)體里）

4，每一層（UI—>BLL—>DAL）之間的數(shù)據(jù)傳遞（單向）是靠變量或?qū)嶓w作為參數(shù)來(lái)傳遞的，這樣就構(gòu)造了三層之間的聯(lián)系，完成了功能的實(shí)現(xiàn)。

但是對(duì)于大量的數(shù)據(jù)來(lái)說(shuō)，用變量做參數(shù)有些復(fù)雜，因?yàn)閰?shù)量太多，容易搞混。比如：我要把員工信息傳遞到下層，信息包括：?jiǎn)T工號(hào)、姓名、年齡、性別、工資．．．．用變量做參數(shù)的話，那么我們的方法中的參數(shù)就會(huì)很多，極有可能在使用時(shí)，將參數(shù)匹配搞混。這時(shí)候，如果用實(shí)體做參數(shù)，就會(huì)很方便，不用考慮參數(shù)匹配的問題，用到實(shí)體中哪個(gè)屬性拿來(lái)直接用就可以，很方便。這樣做也提高了效率。

（注：這里為什么說(shuō)可以暫時(shí)理解為每個(gè)數(shù)據(jù)表對(duì)應(yīng)一個(gè)實(shí)體？？答：大家都知道，我們做系統(tǒng)的目的，是為用戶提供服務(wù)，用戶可不關(guān)心你的系統(tǒng)后臺(tái)是怎么工作的，用戶只關(guān)心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那么數(shù)據(jù)庫(kù)中也要有相應(yīng)的增、刪、改、查，而增刪改查具體操作對(duì)象就是數(shù)據(jù)庫(kù)中的數(shù)據(jù)，說(shuō)白了就是表中的字段。所以，將每個(gè)數(shù)據(jù)表作為一個(gè)實(shí)體類，實(shí)體類封裝的屬性對(duì)應(yīng)到表中的字段，這樣的話，實(shí)體在貫穿于三層之間時(shí)，就可以實(shí)現(xiàn)增刪改查數(shù)據(jù)了）

綜上所述:三層及實(shí)體層之間的依賴關(guān)系:

思想來(lái)源于生活：

服務(wù)員：只管接待客人；

廚師：只管做客人點(diǎn)的菜；

采購(gòu)員：只管按客人點(diǎn)菜的要求采購(gòu)食材；

他們各負(fù)其職，服務(wù)員不用了解廚師如何做菜，不用了解采購(gòu)員如何采購(gòu)食材；廚師不用知道服務(wù)員接待了哪位客人，不用知道采購(gòu)員如何采購(gòu)食材；同樣，采購(gòu)員不用知道服務(wù)員接待了哪位客人，不用知道廚師如何做菜。

他們?nèi)呤侨绾温?lián)系的？

比如：廚師會(huì)做：炒茄子、炒雞蛋、炒面——此時(shí)構(gòu)建三個(gè)方法（ cookEggplant()、cookEgg()、cookNoodle())

顧客直接和服務(wù)員打交道，顧客和服務(wù)員（UI層）說(shuō)：我要一個(gè)炒茄子，而服務(wù)員不負(fù)責(zé)炒茄子，她就把請(qǐng)求往上遞交，傳遞給廚師（BLL層），廚師需要茄子，就把請(qǐng)求往上遞交，傳遞給采購(gòu)員（DAL層），采購(gòu)員從倉(cāng)庫(kù)里取來(lái)茄子傳回給廚師，廚師響應(yīng)cookEggplant()方法，做好炒茄子后，又傳回給服務(wù)員，服務(wù)員把茄子呈現(xiàn)給顧客。

這樣就完成了一個(gè)完整的操作。

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

這樣講，不知道大家是不是可以明白。（待會(huì)實(shí)例解釋吧）

2，為什么使用三層？

使用三層架構(gòu)的目的：解耦！！！

同樣拿上面飯店的例子來(lái)講：

（1）服務(wù)員（UI層）請(qǐng)假——另找服務(wù)員；廚師（BLL層）辭職——招聘另一個(gè)廚師；采購(gòu)員（DAL）辭職——招聘另一個(gè)采購(gòu)員；

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

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

任何一層發(fā)生變化都不會(huì)影響到另外一層！！！

3，與兩層的區(qū)別？？

兩層：

（當(dāng)任何一個(gè)地方發(fā)生變化時(shí)，都需要重新開發(fā)整個(gè)系統(tǒng)。“多層”放在一層，分工不明確耦合度高——難以適應(yīng)需求變化，可維護(hù)性低、可擴(kuò)展性低）

三層：

（發(fā)生在哪一層的變化，只需更改該層，不需要更改整個(gè)系統(tǒng)。層次清晰，分工明確，每層之間耦合度低——提高了效率，適應(yīng)需求變化，可維護(hù)性高，可擴(kuò)展性高）

綜上：三層架構(gòu)的

優(yōu)勢(shì)：1，結(jié)構(gòu)清晰、耦合度低,2，可維護(hù)性高，可擴(kuò)展性高；3，利于開發(fā)任務(wù)同步進(jìn)行；容易適應(yīng)需求變化

劣勢(shì)：1、降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫(kù)，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來(lái)完成。

2、有時(shí)會(huì)導(dǎo)致級(jí)聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個(gè)功能，為保證其設(shè)計(jì)符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼

3、增加了代碼量，增加了工作量

4,三層的具體表現(xiàn)形式？？

UI：

（大家不要誤會(huì)，UI層不只是一個(gè)個(gè)用戶界面，也是需要有代碼的）

(1,功能：用戶輸入數(shù)據(jù)、反饋給用戶數(shù)據(jù)；2,大家觀察代碼:沒有涉及到業(yè)務(wù)邏輯，直接傳參、函數(shù)、方法調(diào)用，沒有涉及到與數(shù)據(jù)庫(kù)打交道的SQL語(yǔ)句和ADO.net)

BLL：

（1，BLL是表示層與數(shù)據(jù)訪問層之間的橋梁，負(fù)責(zé)數(shù)據(jù)處理、傳遞；2，大家觀察代碼，沒有涉及到界面上的控件，沒有涉及到SQL語(yǔ)句和ADO.net）

DAL：

(1,以上是DAL層中DbUtil類、user_DA類和workRecord_DA類中的代碼;2,大家觀察代碼，沒有涉及到界面控件，沒有涉及到業(yè)務(wù)邏輯；只有與數(shù)據(jù)庫(kù)打交道的SQL語(yǔ)句和ADO.net)

Entity（Model）層：

（定義了實(shí)體類user）

觀察以上三層：

1，實(shí)體類user作為參數(shù)貫穿于三層之間；

2，通過傳參、方法調(diào)用來(lái)實(shí)現(xiàn)功能；

3，各層之間各負(fù)其責(zé)；互不影響

對(duì)比兩層結(jié)構(gòu)，讓大家深刻體會(huì)三層的極大好處：

還是以機(jī)房收費(fèi)系統(tǒng)的登陸為例：

（觀察上面的兩層的代碼：將業(yè)務(wù)邏輯、數(shù)據(jù)訪問都展現(xiàn)在用戶表現(xiàn)層，當(dāng)需求需要改變時(shí)，需要改變整個(gè)系統(tǒng)。比如，我把文本框txtPassWord的名稱改為txtPwd的話，大家觀察一下得需要更改多少地方。這樣的改動(dòng)算是小的，如果真的有業(yè)務(wù)需求上的改動(dòng)才叫麻煩復(fù)雜，程序員不跳樓才怪。呵呵、、開個(gè)玩笑）

與如此難以適應(yīng)需求變化的兩層相比，大家再次觀察三層代碼，再次思考，三層架構(gòu)有什么好處呢？自己思考。。。。。

自己去發(fā)掘吧！！！

總結(jié)

以上是生活随笔為你收集整理的三层架构的上位机软件开发的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。