三層架構（3-TIerarchitecture）通常意義上的三層架構就是將整個業務應用劃分為：介面層（UserInterfacelayer）、業務邏輯層（BusinessLogicLayer）、資料訪問層（Dataaccesslayer）。區分層次的目的即為了“高內聚低耦合”的思想。在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或稱為領域層）、表示層。
1：資料訪問層：主要是對非原始資料（資料庫或者文字檔案等存放資料的形式）的操作層，而不是指原始資料，也就是說，是對資料庫的操作，而不是資料，具體為業務邏輯層或表示層提供資料服務。

2：業務邏輯層：主要是針對具體的問題的操作，也可以理解成對資料層的操作，對資料業務邏輯處理，如果說資料層是積木，那邏輯層就是對這些積木的搭建。

3：介面層：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表現成：aspx，如果邏輯層相當強大和完善，無論表現層如何定義和更改，邏輯層都能完善地提供服務。

表示層的內容就是來和使用者打交道，通俗講就是展現給使用者的介面，使用者的要求都體現在介面上。

三層架構的原理及實現_三層架構怎麼用----各層之間的關係

業務邏輯層的功能主要是實現一些具體問題的操作，它是表示層和資料訪問層之間溝通的橋樑，主要負責資料的傳遞和處理。

資料訪問層的功能就是對資料庫中表的內容的增刪改查。

三層的實現將我們的系統的實現過程分門別類，每一層自己做自己的事，互不影響，當我需要其他層的內容時，再去呼叫。當需要修改時只需改動本層的內容，不會影響到整個系統的程式碼。

就是傳說中的解耦。讓那個每一層只關心自己內部的事情，它只知道下層的存在，不知道上層的存在。達到區域性改變而不影響全域性的目的！

三層結構的程式不是說把專案分成DAL，BLL，WebUI三個模組就叫三層了，下面幾個問題在你的專案裡面：

⒈ UILayer裡面只有少量（或者沒有）SQL語句或者儲存過程呼叫，並且這些語句保證不會修改資料？

⒉ 如果把UILayer拿掉，你的專案還能在Interface/API的層次上提供所有功能嗎？

⒊ 你的DAL可以移植到其他類似環境的專案嗎？

⒋ 三個模組，可以分別運行於不同的伺服器嗎？

如果不是所有答案都為YES，那麼你的專案還不能算是嚴格意義上的三層程式。 三層程式有一些需要約定遵守的規則：

⒈ 最關鍵的，UI層只能作為一個外殼，不能包含任何業務邏輯（BizLogic）的處理過程

⒉ 設計時應該從BLL出發，而不是UI出發。 BLL層在API上應該實現所有BizLogic，以面向物件的方式

⒊ 不管資料層是一個簡單的SqlHelper也好，還是帶有Mapping過的Classes也好，應該在一定的抽象程度上做到系統無關

⒋ 不管使用COM+（Enterprise Service），還是RemoTIng，還是WebService之類的遠端物件技術，不管部署的時候是不是真的分別部署到不同的伺服器上，最起碼在設計的時候要做這樣的考慮，更遠的，還得考慮多臺伺服器通過負載均衡作叢集。

所以考慮一個專案是不是應該應用三層/多層設計時，先得考慮下是不是真的需要？ 實際上大部分程式就開個WebApplicaTIon就足夠了，完全沒必要作的這麼複雜。 而多層結構，是用於解決真正複雜的專案需求的