三層架構和mvc是兩個東西。
非要相關的話：
三層架構中"表現層"的aspx頁面對應mvc中的view（繼承的類不一樣）
三層架構中"表現層"的aspx.cs頁面(類)對應mvc中的controller
三層架構中業務邏輯層和資料訪問層對應mvc中的model
由於層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是「無知」的，改變上層的設計對於其呼叫的底層而言沒有任何影響。如果在分層設計時，遵循了面向介面設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。因而在不改變介面定義的前提下，理想的分層式架構，應該是乙個支援可抽取、可替換的「抽屜」式架構。正因為如此，業務邏輯層的設計對於乙個支援可擴充套件的架構尤為關鍵，因為它扮演了兩個不同的角色。對於資料訪問層而言，它是呼叫者；對於表示層而言，它卻是被呼叫者。依賴與被依賴的關係都糾結在業務邏輯層上，如何實現依賴關係的解耦，則是除了實現業務邏輯之外留給設計師的任務。
1、表現層（ui）：通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。（負責展示而已）
2、業務邏輯層（bll）：針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。（關鍵在於由原始資料抽象出邏輯資料）能夠提供inte***ce\api層次上所有的功能。，「中間業務層」的實際目的是將「資料訪問層」的最基礎的儲存邏輯組合起來，形成一種業務規則
3、資料訪問層（dal）：該層所做事務直接運算元據庫，針對資料的增添、刪除、修改、查詢等。（關鍵在於粒度的把握）要保證「資料訪問層」的中的函式功能的原子性！即最小性和不可再分。「資料訪問層」只管負責儲存或讀取資料就可以了。
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為：資料訪問層、業務邏輯層（又或稱為領域層）、表示層。
三層結構原理：
3個層次中，系統主要功能和業務邏輯都在業務邏輯層進行處理。
所謂三層體系結構，是在客戶端與資料庫之間加入了乙個「中間層」，也叫元件層。這裡所說的三層體系，不是指物理上的三層，不是簡單地放置三颱機器就是三層體系結構，也不僅僅有b/s應用才是三層體系結構，三層是指邏輯上的三層，即使這三個層放置到一台機器上。
三層體系的應用程式將業務規則、資料訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與資料庫進行互動，而是通過com/dcom通訊與中間層建立連線，再經由中間層與資料庫進行互動。
各層的作用1：資料資料訪問層:主要是對原始資料（資料庫或者文字檔案等存放資料的形式）的操作層，而不是指原始資料，也就是說，是對資料的操作，而不是資料庫,具體為業務邏輯層或表示層提供資料服務．
2：業務邏輯層:主要是針對具體的問題的操作，也可以理解成對資料層的操作,對資料業務邏輯處理，如果說資料層是積木，那邏輯層就是對這些積木的搭建。
3：表示層:主要表示web方式,也可以表示成winform方式,web方式也可以表現成:aspx, 如果邏輯層相當強大和完善,無論表現層如何定義和更改,邏輯層都能完善地提供服務。
具體的區分方法
1：資料資料訪問層:主要看你的資料層裡面有沒有包含邏輯處理，實際上他的各個函式主要完成各個對資料檔案的操作。而不必管其他操作。
2：業務邏輯層:主要負責對資料層的操作。也就是說把一些資料層的操作進行組合。
3：表示層:主要對使用者的請求接受，以及資料的返回，為客戶端提**用程式的訪問。
位於最外層（最上層），離使用者最近。用於顯示資料和接收使用者輸入的資料，為使用者提供一種互動式操作的介面。
業務邏輯層在體系架構中的位置很關鍵，它處於資料訪問層與表示層中間，起到了資料交換中承上啟下的作用。由於層是一種弱耦合結構，層與層之間的依賴是向下的，底層對於上層而言是「無知」的，改變上層的設計對於其呼叫的底層而言沒有任何影響。如果在分層設計時，遵循了面向介面設計的思想，那麼這種向下的依賴也應該是一種弱依賴關係。因而在不改變介面定義的前提下，理想的分層式架構，應該是乙個支援可抽取、可替換的「抽屜」式架構。正因為如此，業務邏輯層的設計對於乙個支援可擴充套件的架構尤為關鍵，因為它扮演了兩個不同的角色。對於資料訪問層而言，它是呼叫者；對於表示層而言，它卻是被呼叫者。依賴與被依賴的關係都糾結在業務邏輯層上，如何實現依賴關係的解耦，則是除了實現業務邏輯之外留給設計師的任務。
資料訪問層：有時候也稱為是持久層，其功能主要是負責資料庫的訪問，可以訪問資料庫系統、二進位制檔案、文字文件或是xml文件。
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的復用。
1、降低了系統的效能。這是不言而喻的。如果不採用分層式結構，很多業務可以直接造訪資料庫，以此獲取相應的資料，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加乙個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和資料訪問層中都增加相應的**。
3、增加了開發成本。
三層結構的程式不是說把專案分成dal, bll, webui三個模組就叫三層了, 下面幾個問題在你的專案裡面：
1. uilayer裡面只有少量(或者沒有)的sql語句或者儲存過程呼叫, 並且這些語句保證不會修改資料?
2. 如果把uilayer拿掉, 你的專案還能在inte***ce/api的層次上提供所有功能嗎?
3. 你的dal可以移植到其他類似環境的專案嗎?
4. 三個模組, 可以分別執行於不同的伺服器嗎?
如果不是所有答案都為yes, 那麼你的專案還不能算是嚴格意義上的三層程式. 三層程式有一些需要約定遵守的規則：
1. 最關鍵的, ui層只能作為乙個外殼, 不能包含任何bizlogic的處理過程
2. 設計時應該從bll出發, 而不是ui出發. bll層在api上應該實現所有bizlogic, 以物件導向的方式
4. 不管使用com+(enterprise service), 還是remoting, 還是webservice之類的遠端物件技術, 不管部署的時候是不是真的分別部署到不同的伺服器上, 最起碼在設計的時候要做這樣的考慮, 更遠的, 還得考慮多台伺服器通過負載均衡作集群
mvc（模型model-檢視view-控制器controller）是一種設計模式，我們可以用它來建立在域物件和ui表示層物件之間的區分。
同樣是架構級別的，相同的地方在於他們都有乙個表現層，但是他們不同的地方在於其他的兩個層。
在三層架構中沒有定義controller的概念。這是我認為最不同的地方。而mvc也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或mvc搭建程式最主要的區別。當然了。在三層中也提到了model，但是三層架構中model的概念與mvc中model的概念是不一樣的，「三層」中典型的model層是以實體類構成的，而mvc裡，則是由業務邏輯與訪問資料組成的。
三層架構 表示層 業務邏輯層 資料訪問層2
在軟體體系架構設計中，分層式結構是最常見，也是最重要的一種結構。微軟推薦的分層式結構一般分為三層，從下至上分別為 資料訪問層 業務邏輯層 又或稱為領域層 表示層。三層結構原理 3個層次中，系統主要功能和業務邏輯都在業務邏輯層進行處理。所謂三層體系結構，是在客戶端與資料庫之間加入了乙個 中間層 也叫元...
三層架構 資料訪問層 業務邏輯層 表示層
三層架構 資料訪問層 業務邏輯層 表示層方便團隊開發，復用 不屬於三層，但跟三層息息相關 實體類 跟資料庫表對應的類 資料訪問層 連線資料庫，執行sql語句 cn.edu.xcu.sims.dao basedao 增刪改的封裝 public int executeupdate string sql,...
三層業務邏輯
1.確定需求 2.根據需求確定sql 3.編寫資料訪問層類，dal 4.編寫業務層 bll 5.編寫表現層 ui 三層結構常用類庫 dal 資料訪問類 bll 業務類 ui 表現層 視窗，多窗體傳值的靜態類gloabhelper model 實體類 資料例項物件 utility 實用類 comman...