首先,
mvc和三層架構，是不一樣的。
三層架構中，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是微軟在2023年4月份發布的一種新的**開發架構，
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模式可以較為隨意。
所以呢，你可以完全不用orm那套東西，直接用**生成器，生成三層架構，把web層換成mvc模式的，like this:
三層架構專案開發
常見的三層架構包括如下幾個部分 資料訪問層 dal 用於實現與資料庫的互動和訪問，從資料庫獲取資料或儲存資料到資料庫的部分。業務邏輯層 bll 業務邏輯層承上啟下，用於對上下互動的資料進行邏輯處理，實現業務目標。表示層 web 主要實現和使用者的互動，接受使用者請求或返回使用者請求的資料結果的展現，...
分層開發（三層架構）
為了實現 高內聚 低耦合 採用 分而治之 的思想，把問題劃分開來各個解決，易於控制，易於延展，易於分配資源。分層的好處 1.實現了軟體之間的解耦，降低元件之間的耦合度 耦合 元件或者 之間的關聯程度 2.便於進行分工，提高開發效率，保證開發質量 3.便於維護 4.提高軟體元件的重用 6.便於產品功能...
WEB開發三層架構概述
關於 表現層 ui 通俗講就是展現給使用者的介面，即使用者在使用乙個系統的時候他的所見所得。業務邏輯層 bll 針對具體問題的操作，也可以說是對資料層的操作，對資料業務邏輯處理。資料訪問層 dal 該層所做事務直接運算元據庫，針對資料的增 刪 改 查。概述 在軟體體系架構設計中，分層式結構是最常見，...