1、開發人員可以只關注整個結構中的其中某一層；2、可以很容易的用新的實現來替換原有層次的實現；3、可以降低層與層之間的依賴；4、有利於標準化；5、利於各層邏輯的復用。6..方便團隊分工
將整個業務應用劃分為：表現層（
ui）、業務邏輯層（
bll）、資料訪問層（
dal）。區分層次的目的即為了
「高內聚，低耦合
」的思想。
1. 表現層
位於最外層（最上層），離使用者最近。用於顯示資料和接收使用者輸入的資料，為
使用者提供一種互動式操作的介面。它是系統的ui部分，負責使用者與整個系統的互動。在這一層中，理想的狀態是不應包括系統的業務邏輯。表示層中的邏輯**，僅與介面元素有關。
2. 業務邏輯層
業務邏輯層（business logiclayer）無疑是系統架構中體現核心價值的部分。它的關注點主要集中在業務規則的制定、業務流程的實現等與業務需求有關的系統設計，也即是說它是與系統所應對的領域（domain）邏輯有關，很多時候，也將業務邏輯層稱為領域層。業務邏輯層在體系架構中的位置很關鍵，它處於資料訪問層與表示層中間，起到了資料交換中承上啟下的作用。
由於層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是「無知」的，改變上層的設計對於其呼叫的底層而言沒有任何影響。如果在分層設計時，遵循了面向介面設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。因而在不改變介面定義的前提下，理想的分層式架構，應該是乙個支援可抽取、可替換的「抽屜」式架構。
正因為如此，業務邏輯層的設計對於乙個支援可擴充套件的架構尤為關鍵，因為它扮演了兩個不同的角色。對於資料訪問層而言，它是呼叫者；對於表示層而言，它卻是被呼叫者。依賴與被依賴的關係都糾結在業務邏輯層上，如何實現依賴關係的解耦，則是除了實現業務邏輯之外留給設計師的任務。
3. 資料訪問層
1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
三層架構並不能提高專案的執行效率，相反由於表現層只能訪問邏輯層，再邏輯層訪問資料訪問層，因此犧牲了效率。但這一缺陷比起它的優勢，在現在硬體品質高速發展的時代幾乎可以忽略不計。
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。完善的三層結構的要求是：修改表現層而不用修改邏輯層，修改邏輯層而不用修改資料層，
否則你的應用是不是
多層結構
，或者說是層結構的劃分和組織上是不是有問題就很難說
.不同的應用有不同的理解，這是乙個概念的問題．
三層架構 理論篇
通常意義上的三層架構就是將整個業務應用劃分為 表現層 ui 業務邏輯層 bll 資料訪問層 dal 區分層次的目的即為了 高內聚。低耦合 的思想。1 表現層 ui 通俗講就是展現給使用者的介面。即使用者在使用乙個系統的時候他的所見所得。2 業務邏輯層 bll 針對詳細問題的操作，也能夠說是對資料層的...
三層 我眼中的三層結構
從行為型模式命令模式引發的對三層的思考。記得 大話設計模式 中對命令模式的講解。燒烤攤和燒烤店之間的區別。由於客戶和烤羊肉串老闆的 緊耦合 所以容易出錯，容易混亂，也容易挑剔。這其實就是 行為請求者 與 行為實現者 的緊耦合。對請求排隊或記錄請求日誌，以及支援可撤銷的操作等行為時，行為請求者 與 行...
三層架構 實踐篇
層 呼叫ui層 model bll bll層 model dll dll層 model 最後就是 實現部分 model層namespace login.model public string username public string password public string email ui...