三層架構中，DAL(數據訪問層)、BLL(業務邏輯層)、WEB層各司其職，意在職責分離。
MVC是 Model-View-Controller，嚴格說這三個加起來之後纔是三層架構中的 WEB層，也就是說， MVC把三層架構中的WEB層再度進行了分化，分紅了控制器、視圖、實體三個部分，控制器完成頁面邏輯，經過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。
因此， .net的三層結構中，並無action這個概念。
asp.net mvc 是微軟新發布的一種網站開發架構。爲了解決傳統 asp.net開發中不能分離Model,View和Controller而設計的。
普通的網站爲了解決可移植，可維護，可擴展等問題，會把網站設計成三個獨立的模塊，Model負責 數據庫部分，View負責網頁的界面，而Controller負責界面與數據的交互及業務邏輯，這樣設計的網站若是想設計或者從新開發某一個模塊對其餘的模塊是沒有影響的。可是 asp.net的頁面後臺代碼與每一個頁面代碼都是一一對應的，業務邏輯在某些狀況下不可避免的被寫到了與View關聯的後臺代碼中。這樣就不能保證View與Controller的分離，也就很難實現網站的重寫和升級。
而在 MVC中頁面代碼並非與後臺代碼一一對應，而是分別被存放成Controller和View兩個部分，完全的解決了，View和Controller不能獨立的問題。從而改善網站的重寫和升級過程。
可是 MVC也有其缺點，因爲在頁面代碼中再也不可使用 服務器控件，所以給某些 asp.net 服務器端控件的使用帶來了麻煩，並且 MVC也頁面的設計工做帶來了不少障礙。
ASP.NET MVC 是微軟在2009年4月份發佈的一種新的網站開發架構，http://msdn.microsoft.com/en-us/library/dd394709.a spx，它是把傳統意義上的 MVC開發思想融合到了 ASP.NET的開發當中。
那麼我也來說講我對這二者的理解吧。
首先對這個題目，自己是存在問題的，"XX結構"與"XX模式"的區別？請問中國社會制度與美國人生活方式有什麼區別？
這二者自己講的是不一樣方向與角度的問題，在實際應用中他們的確存在一些類似的特色，在不少 書籍中也沒有深刻講解，以至於形成困惑，爲了更好的理解他們，姑且來講說區別吧。
首先N層結構是一種軟件抽象的層次結構，是對複雜軟件的一種縱向切分，每一層次中完成同一類型的操做，以便將各類代碼以其完成的使命做爲依據來分割，以將低軟件的複雜度，提升其可維護性。通常來講，層次之間是向下依賴的，下層代碼未肯定其接口（契約）前，上層代碼是沒法開發的，下層代碼接口（契約）的變化將使上層的代碼一塊兒變化。三層結構是N層結構的一種，是人產在長時間使用中得出來的一種應用場合普遍的N層結構，被看成一種典型的軟件層次結構而廣爲流傳甚至寫入教科書。
MVC模式是一種複合設計模式，一種在特定場合用於解決某種實際問題來得出的能夠反覆實踐的解決方案。巧合的是他也有三個事物組成，因而乎人們就有了一種想固然的對應關係：展現層-View；業務邏輯層-Control；持久層-Model。首先 MVC中的三個事物之間並不存在明顯的層次結構，沒有明顯的向下依賴關係，相反的，View和Model每每是比較獨立的，而Control是鏈接二者的橋樑，他們更像是橫向的切分。這樣一來就出現一個結果， MVC中每一個塊都是能夠獨立測試的，而三層結構中，上層模塊的運行測試勢必要提供下層代碼或者提供相同接口的樁。相對來講， MVC複雜得多，可是結構更清晰，耦合性更低。
另外， MVC中每一塊內部特別是Model內部常常被設計爲多層的。在我認爲的一個良好的 MVC模式構建的結構中，Control是核心，小且較爲穩定的，能夠做爲一個核心框架來提供，有擴展點，但基本上能夠簡單配置不須要任何代碼就能夠運行。而View則多是一套或多種可選擇的視圖引擎，決定了軟件展現給用於的界面，使用時的主要工做量在於擴展點以及根據須要而數量不一樣的視圖模板。Model則是業務提供者，決定了軟件提供的功能，其內部多是一些普通的類或者是實現了某些接口的類，在這一塊當中可能根據業務的不一樣而色彩繽紛，對於複雜的軟件可能會分紅不少層，如業務邏輯層、業務提供層、系統提供層、數據提供層、數據訪問層等。
我常常用於比喻 MVC的例子是小時候玩的那種卡帶式遊戲機，Control是主機，通常來講我買一個主機就好了，只要他不壞，他就能一直讓我玩這一類的遊戲。View則是電視機和遊戲手柄，電視機能夠獨立工做，他無論輸入的是電視信號、影碟機信號仍是遊戲機信號，他只管顯示，並且他決定了咱們看到的效果是怎麼樣的，若是我想要個尺寸更大的或者彩色的顯示效果，我只須要買個相應的電視機就好了，手柄也是能夠換的，要遙杆仍是帶震動的。Model則是遊戲卡帶，他絕定了我玩的是什麼遊戲，是魂鬥羅仍是超級瑪莉，並且遊戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什麼樣的遊戲。卡帶中可能會有遊戲代碼和存儲單元，都根據遊戲的須要而設計。
有朋友提到遊戲主機提供的卡帶插槽的接口，在設計中，有時也由Control提供一組接口，以用於Model或View的實現，這樣就造成了依賴。通常來講這樣設計也沒有太大的問題，只是會提升模塊間的耦合度，也會帶來一些侵入性。爲了更完美，能夠不用接口來提供契約，能夠用配置信息（或稱元數據信息）+反射來提供契約，那麼這個類接口就能夠退化到只要符合CLS就能夠了，也就是普通的類，就像如今的計算機接口普遍採用USB，不管是U盤、打印機、掃描儀或者是 加密狗，他們都是普通的USB設備而已。
提到USB有一個題外話，模塊的可插拔性設計甚至是熱插拔設計，系統能夠在不中止運行的狀況下動態的掛載或移除模塊，動態掛載模塊須要系統可以自動發現新模塊並根據自描述的信息進行自動配置，移除可能狀況更復雜一點，須要"安全刪除硬件"相似的功能。
在設計普遍重用的框架時會考慮多種狀況以達到更大的適應性，通常項目中應用MVC模式能夠較爲隨意。html
因此呢，你能夠徹底不用ORM那套東西，直接用代碼生成器，生成三層架構，把WEB層換成mvc模式的，like this:linux
