1,什么是三層？

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

?

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

?

DAL:(數據訪問層):與數據庫打交道。主要實現對數據的增、刪、改、查。將存儲在數據庫中的數據提交給業務層，同時將業務層處理的數據保存到數據庫。（當然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，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：

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

?

BLL：

?

?

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

?

DAL：

?

(1,沒有涉及到界面控件，沒有涉及到業務邏輯；只有與數據庫打交道的SQL語句和ADO.net)

?

Entity（Model）層：

?

（定義了實體類user）

觀察以上三層：

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

2，通過傳參、方法調用來實現功能；

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

轉載于:https://www.cnblogs.com/lubei/p/5046260.html

總結

以上是生活随笔為你收集整理的（转）关于三层架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。