表現層（ui）：通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。
業務邏輯層（bll）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。
資料訪問層（dal）：該層所做事務直接運算元據庫，針對資料的增添、刪除、修改、更新、查詢等。
例子：飯店的這個例子很形象，很容易明白三層的結構以及所體現的思想。
飯店將整個業務分解為三部分來完成，每一部分各負其責，服務員只管接待顧客、向廚師傳遞顧客的需求；廚師只管烹炒不同口味、不同特色的美食；採購員只管提供美食原料；他們三者分工合作共同為顧客提供滿意的服務，並且
服務員、廚師、採購員三者中當任何一者發生變化時都不會影響到其他兩者的正常工作，從而體現了三層結構各層之間的「高內聚，低耦合」特點。
有需求，才有創造，單層或是二層滿足不了程式的需要，於是便有了三層，也就是三層擁有他們所沒有的特點，也就是所謂的優點。
（二層）
其侷限性：
一旦使用者的需求發生變化，應用程式都需要進行大量修改，甚至需要重新開發，給系統的維護和公升級帶來了極大的不便；使用者介面層直接訪問資料庫，會帶來很多安全隱患。
三層優點：
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的復用。
答案顯而易見，如果是小型系統，用二層和三層體會不出三層的優勢，所以用那個都ok了，那麼如果是大型系統，我們要做到「可擴充套件、可維護」，而不至於造成「牽一髮而動全身」，我們要用到三層。
下篇部落格會以登入為例講述三層應該怎麼進行。
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
我對三層架構的理解
三層介紹及其的職責 層之間的關係以及規則 三層架構的優缺點總結 概念 資料訪問層 dal 主要負責對資料庫的直接訪問，向上層遮蔽資料庫差異。關係 規則優點 降低維護成本，方便管理。對於不斷變化的系統有著先天的優勢。遮蔽資料庫差異。適合大型專案及合作開發。安全性。缺點執行速度。量大。層次的劃分並不是死...
我對三層架構的理解
架構 有1多點的時間了吧。但是什麼架構才是真正的好的架構的架構呢？不得而知。真正的運用於每個系統，作用於每個系統得東西才是好的吧。三層，乙個很通用的架構，其優點，便於 維護和後續開發。說實話，感覺還是有些不敢苟同。便於 維護，如果說到 維護我把dal層和bll 資料訪問層和業務邏輯層 結合成一層也沒...