三層一般分為兩類：實體上的三層和邏輯上的三層架構；實體三層架構是以邏輯的三層架構為基礎的，如果沒有了邏輯的三層，就根本談不上實體三層架構的部署。
什麼是實體三層架構呢？
從簡單了說就是每一層都分别做成一個元件，如業務邏輯元件，業務實體元件，資料通路元件等。在到複雜一些就是建構分布式系統，例如将業務邏輯層與資料通路分别部署在不同的伺服器上。
我們這裡講的主要是邏輯上的三層架構。
三層基礎知識
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分别為：資料通路層、業務邏輯層（又或稱為領域層）、表示層。
那麼每層都有什麼作用呢，見下表：
作用
設計原則
常用技術
表示層(ui)
向使用者展現特定業務資料，采集使用者的輸入資訊和操作
使用者至上，兼顧簡潔；不包含任何業務相關的邏輯處理
windowsＦｏｒｍ＼ＡＳＰ.ＮＥＴ
業務邏輯層(bll)
從ＤＡＬ中擷取資料，在ＵＩ顯示；從ＵＩ中擷取使用者指令和資料，執行業務邏輯或通過ＤＡＬ寫入資料源。
作為u層與Ｄ層的橋梁，隻負責資料處理傳遞，不涉及ＳＱＬ語句和ＡＤＯ.ＮＥＴ
——————————————
資料通路層(dal)
直接操作資料庫，針對資料的增添、删除、修改、查找；具體為業務邏輯層或表示層提供資料服務。
隻提供基本的資料通路，不包含任何業務邏輯處理。
ＡＤＯ.ＮＥＴ＋ＳＱＬ語句；ＯＲＭ架構；Ｌｉｎｑ Ｔｏ ＳＱＬ
三層結構圖：
說到三層，大家是不是想知道有沒有兩層結構，答案是有！而且就在我們身邊．以前我們的作品展，資訊管理系統，第一遍機房收費，都是典型兩層結構。
兩層結構圖：
從圖中就可以看出，兩層結構把界面，邏輯和資料通路統統放在了一起，互相糾纏．導緻了高耦合，難複用而且當需求變更時所面臨的很可能是重新開發．當然更别說後期的維護問題了。
相比于兩層架構而言，三層有很多優勢：
1、開發人員可以隻關注整個結構中的其中某一層； 2、可以很容易的用新的實作來替換原有層次的實作； 3、可以降低層與層之間的依賴； 4、有利于标準化； 5、利于各層邏輯的複用。 6、結構更加的明确 7、在後期維護的時候，極大地降低了維護成本和維護時間
當然有這麼多的優勢，并不意味着所有的程式都需要應用三層架構，一些簡單的小程式的編寫完全沒必要這麼複雜，而一些真正複雜的項目，三層有時候不夠用，需要多層結構。
金無足赤，和設計模式一樣，三層架構也有他的一些小缺點：
1、降低了系統的性能。這是不言而喻的。如果不采用分層式結構，很多業務可以直接造訪資料庫，以此擷取相應的資料，如今卻必須通過中間層來完成。 2、有時會導緻級聯的修改。這種修改尤其展現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料通路層中都增加相應的代碼。 3、增加了開發成本。
基礎的知識就說到這，我們能不能從生活中找到三層的影子呢？
我想起了有次暑假打工的經曆，那是在一家酒店做的廚師助理。呵呵，這麼好聽的名字，說白了就是打雜的，所做的工作就是：從倉庫中幫廚師找到做某道菜需要的食材，配料等。
酒店的服務工作流程是這樣的，服務員負責接待顧客，顧客通過菜單點了某些菜，服務員将顧客點的菜單送出給廚師，然後根據菜單所需，轉告廚師助理去提取相應的原料，然後廚師将這些原料制作成美味的佳肴轉交給服務員，服務員再将佳肴交給顧客，顧客在享用這些美味。
是不是有種很熟悉的感覺，服務員，廚師，助理 不正是很好的解釋了三層架構嗎？
服務員（表示層）：負責前台的工作與顧客（客戶）打交道。 廚師（業務邏輯層）：負責具體制作某些菜（邏輯處理） 助理（資料通路）：負責從倉庫（資料庫）中尋找某些食材配料（資料）
知識來源于生活，聯系生活來學習更有助于了解。
學了設計模式和三層才知道，作品展、學生系統、第一遍機房收費系統等都是在搭雞窩，所有的代碼都放在一個個窗體裡面，而且窗體間耦合還巨強，汗。。