注：本文章內所有內容都來自互聯網，本人主要是起了一個收集的作用
http://www.cnblogs.com/zhhh/archive/2011/06/10/2077519.html
又看到有人在問三層架構和MVC的關係，感覺這種問題有點教條化了。因爲它們都在邏輯上將應用程序劃爲三塊，湊了一個數字3，就有人非要把它們聯繫到一起了。
這兩個東西我接觸有幾年了，有一點體會，表達一下：
三層是三層，MVC是MVC，它們毫無關係的。
三層是從整個應用程序架構的角度來分的三層（如果程序需要，還可以分多層）。
三層是爲了解決整個應用程序中各個業務操作過程中不同階段的代碼封裝的問題，爲了使程序員更加專注的處理某階段的業務邏輯。
比如將數據庫操作代碼封裝到一層中，提供一些方法根據參數直接返回用戶需要的相應數據，這樣在處理具體的業務邏輯的時候，就不用關心數據的存儲問題了。
MVC是在應用程序（BS結構）的視圖層劃分出來的不同功能的幾個模塊。
MVC主要是爲了解決應用程序用戶界面的樣式替換問題，把展示數據的 HTML 頁面儘可能的和業務代碼分離。MVC把純淨的界面展示邏輯（用戶界面）獨立到一些文件中（Views），把一些和用戶交互的程序邏輯（Controller）單獨放在一些文件中，在 Views 和 Controller 中傳遞數據使用一些專門封裝數據的實體對象，這些對象，統稱爲Models。
只所以說MVC和三層毫無關係，是因爲它們二者使用範圍不同：三層可以應用於任何語言、任何技術的應用程序；而MVC只是爲了解決BS應用程序視圖層各部分的耦合關係。它們互不衝突，可以同時存在，也可根據情況使用其中一種。
http://blog.csdn.net/beijiguangyong/article/details/7029257
三層架構就是MVC！
起初老師總說三層MVC，MVC三層架構……
所以開始的時候腦子就一個概念：三層就是MVC，MVC就是三層架構。而且想想也合理啊，都是“三”。MVC是三個字母，三層架構也是“三”，理所應當的就對應上了。然後就這麼一直“錯”了很長時間。
三層架構絕不是MVC！！
後來學習了J2EE之後發現老師說的好像不對，MVC和三層架構不是一個東西。三層架構是界面層（UI）業務邏輯層（BLL）和數據訪問層（DAL）構成的，而MVC是模型層（M）界面層（View）和控制層（Controller）構成的，而且他們之間也不對應。
如果硬要給他們對應的話，那麼三層架構中的UI對應MVC中的view（jsp），都是用於顯示以及獲取界面的數據；三層架構中的BLL層和DAL層對應MVC中的Model（javabean）層都是用於處理上層傳遞來的數據以及從數據庫獲取的數據的；MVC中的Controller（Servlet）最多算是三層架構中的UI的一部分，也就我們常說的是Servlet。
如下圖所示：
頓時感到世界明朗了，對分層又深入瞭解了一步。
其實三層架構和MVC還是一個東西！！！
這幾天一直在思考三層架構和MVC到底是個什麼關係，老師爲什麼起初會放在一起說嘞？然後恍然大悟：其實三層架構和MVC是一樣的！！！我們所看到的不一樣只是表面上的不一樣。核心的東西是一致的，那麼什麼是核心？
答曰：分層，解耦！
如果從解耦的角度來看三層架構和MVC其實他們是一致的，只不過劃分的方法不一樣罷了，就像上面的圖所示。從這一點說他們可以說是一個東西。這就相當於我們看到饅頭和麪條一樣，表面上看他們不一樣（注意僅僅是表面）但是他們核心是一致的，都是面……
知識的學習過程就要像老牛反芻一樣，需要不斷的加深認識，最終才能真正領悟
對事物的認識是從感性到理性的，是一步一步的加深的，每一步的加深也許會推翻以前的自己，也許會更加贊同以前的自己。如果是推翻以前的自己那麼代表對這個事物的認識發生了翻天地覆的變化，但是如果讚許以前的自己也並不代表自己的觀點沒有變化，往往表面上看起來一致的東西其實內核並一定是相同的。就像剛開始的時候認爲三層架構和MVC是一個東西到最後同樣是認爲這兩是一個東西，但是理解的層次絕對是不一樣的。
至於以後會不會再次推翻自己的觀點我不曉得，只能說每次推翻都代表着進步，代表着理解的更深一層，所以我期望着下次的否定自己
http://baike.baidu.com/view/687468.htm
與MVC的區別 MVC（模型Model-視圖View-控制器Controller）是一種設計模式，我們可以用它來創建在域對象和UI表示層對象之間的區分。
同樣是架構級別的，相同的地方在於他們都有一個表現層，但是他們不同的地方在於其他的兩個層。
在三層架構中沒有定義Controller的概念。這是我認爲最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。
http://topic.csdn.net/u/20090710/14/07f4447d-60c4-4b74-af1c-ea1b6e2e9ca7.html
當然啊，你要明白三層架構的MVC的區別和聯繫：
三層架構是最基本的項目分層結果，而MVC則是三層架構的一個變體，MVC是一種好的開發模式。首先你要明白MVC分別代表的是什麼意思.
M 即Model(模型層)，主要負責出來業務邏輯以及數據庫的交互
V 即View(視圖層)，主要用於顯示數據和提交數據
C 即Controller(控制器)，主要是用作捕獲請求並控制請求轉發
三層:UI 界面層 BLL 業務邏輯層，DAL數據訪問層，Model 實體層
MVC中的的M 不是三層中的Model(實體層)，他其實包括三層中的 BLL，DAL,Model,這是非常要注意的，這也是他們之間的區別的關鍵所在
其有點有如下：
低耦合性
高重用性和可適用性
較低的生命週期成本
快速的部署
可維護性
有利於軟件工程化管理
當然優點也有缺點，那就是內部結構複雜，不容易理解，文件數量大，管理難度自然也就大
三層架構…
他們細分之後得到的是：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller
MVC把 BIZ（BLL）、DAO（DAL）、Model（Entity） 統一稱之爲 模型(MODEL)，得到：View、Controller、模型(MODEL)
三層 在我使用中 暫未體會到控制器的存在，完全是：UI、DAO、BLL
他們相同的設計理念就是：把視圖設計與數據持久化進行分離，從而降低耦合性，易於擴展，提高團隊開發效率。
三層是基於業務邏輯來分的，而mvc是基於頁面來分的
根本就沒有什麼可比性。
其實兩個一起用我感覺很好
MVC模式是一種複合設計模式，一種解決方案
三層是種軟件架構，通過接口實現編程
三層模式是體系結構模式，MVC是設計模式
三層模式又可歸於部署模式，MVC可歸於表示模式
沒有什麼取捨的，說的根本不是一回事。在所謂的“三層”中，它要求你將BLL層獨立出來，它只是告訴你表示層和業務邏輯層之間的靜態關係。而MVC則告訴你在這個具體的地方如何處理其動態驅動流程，儘管mvc仍然粗糙（甚至mvp也是粗糙的），但是已經比所謂三層更細緻一些了。
謝謝大家的關注，這幾天都在忙面試，沒來結貼。再次謝謝大家。
我大概明白了：三層架構和mvc設計模式側重點不一樣，三層是一種籠統的架構思想，沒有限制具體的設計；而mvc就比較具體的說明它的設計方法。
還是自己動手做一下，理解會更深一些，以前都是用三層架構的方法
---------------------------------------------------------------------------------------------------------------
http://apps.hi.baidu.com/share/detail/15057889
ASP.NET MVC 與 WebForm 三層架構 區別
1.傳統WebForm開發中存在的一些問題
傳統的ASP.NET開發中，微軟的開發團隊爲開發者設計了一個在可視化設計器中拖放控件，編寫代碼響應事件的快速開發環境。然而，它所帶來的負面效應是：
由於控件封裝了很多東西，開發者很難了解這背後的HTML是如何運作的
容易得到一個包含大量ViewState的頁面，使得頁面尺寸遠遠超過所需的內容，使得頁面的打開速度較慢
不容易被測試
2.什麼是MVC?
MVC（Model-View-Controller，模型-視圖-控制器模式）是軟件工程中的一種軟件架構模式。它把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。
3.什麼是ASP.NET MVC?
ASP.NET MVC是微軟的開發團隊基於MVC開發的一個易於被測試的框架。它具有以下特性：
沒有數據回傳
沒有在頁面中保存視圖狀態
開發者可以完全掌控頁面的呈現過程
易於單元測試
易於測試驅動開發
可擴展、可替換
支持WebForm中的有關特性，如：用戶控件、母版頁、數據綁定、本地化等
不在基於文件目錄結構，而是將URL映射到控制器中
4. 爲什麼使用ASP.NET MVC?
易於進行單元測試
易於進行測試驅動開發
避免了WebForm中大量的ViewState導致頁面文件變得臃腫
5. MVC與三層架構?
MVC是一種模式
ASP.NET MVC是一個基於MVC模式的開發框架
三層架構是一種架構
至於區別，可以嚴格的從概念上區分開來。
下圖是MVC與三層架構的對應關係
6. MVC與Webform如何抉擇?
7. 兩種技術並存
ASP.NET MVC框架只是給開發者提供歐諾個了開發web應用程序的一種選擇，並不是要取代Webform
這兩種技術各有優缺點，開發者需要根據實際情況，選擇對應的技術
有時候，可以在同一個項目中混合使用這兩種技術
8.ASP.NET MVC與Webform技術的架構圖
總結：
看完本文，相信ASP.NET WebForm與ASP.NET MVC的選擇相信大家應該可以做到心中有數了，我始終覺得，很多時候並不是什麼技術好不好的問題，而是適合不適合不適合的問題或者能否把它用好的問題。
打個比方：如果讓千里馬犁地，恐怕未必能達到理想的效果，最終可能還會抱怨，什麼破馬，一點勁都沒有。
========================================================================
http://www.blogjava.net/phyeas/archive/2008/07/01/211995.html
同樣是架構級別的，它們有什麼相同點和不同點呢？這篇文章討論一下它們的異同點。希望能幫助讀者理解其中的玄機。 :)
其實它們相同的地方在於他們都有一個表現層。
但是他們不同的地方在於其他的兩個層。
首先先解釋一下MVC。V即View.是視圖的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。這三個裏.最不容易理解的應該是Model.就是什麼是Model，而爲什麼叫Model。我先不說爲什麼叫Model，先解釋Controler。
Controller是控制器的意思，所謂控制器，就是將用戶請求轉發給模型層，經過處理後把結果返回到界面展現的一箇中間層，那麼Controler到底管什麼工作呢？先不說.先來看下在Java Web中這三個層一般的定義，一般在Java Web裏，JSP充當V，Servlet充當C,JavaBean充當M，這裏的Servlet管什麼工作呢？接受輸入，轉到Model層去處理，處理結果保存後轉發到JSP，然後展現數據。所以它的功能就是控制器的基本功能，它就管轉發，在V和M之間轉來轉去。
再來說說M，即Model，在Java Web裏說的是JavaBean，我認識的很多人都把JavaBean誤認爲是實體類，其實JavaBean有比實體類更豐富的定義，在JavaBean中除了其屬性和字段，還可以有行爲及其事件，JavaBean可以理解爲普通Java對象。Java普通對象，就是符合Java規範的所有對象，這和實體類完全是兩回事。所以，我認爲在MVC中。業務邏輯和數據訪問應該放在Model層，也就是V負責展示數據，Controler除了轉發不做業務邏輯。真正的邏輯事務，數據訪問，甚至算法都放到Model去。
再說三層架構。三層其實很好理解，界面，業務，數據訪問，就這三個，從字面都可以理解出它們的意思。我要說的是它和MVC的區別。在三層架構中沒有定義Controler的概念。這是我認爲最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。
當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是已實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。不一樣的概念。雖然名字一樣。
http://blog.sina.com.cn/s/blog_677b66170100mv16.html
asp.net mvc和三層架構聯繫與區別
首先,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 是微軟在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模式可以較爲隨意。
頓時感到世界明朗了，對分層又深入瞭解了一步。
其實三層架構和MVC還是一個東西！！！
這幾天一直在思考三層架構和MVC到底是個什麼關係，老師爲什麼起初會放在一起說嘞？然後恍然大悟：其實三層架構和MVC是一樣的！！！我們所看到的不一樣只是表面上的不一樣。核心的東西是一致的，那麼什麼是核心？
答曰：分層，解耦！
如果從解耦的角度來看三層架構和MVC其實他們是一致的，只不過劃分的方法不一樣罷了，就像上面的圖所示。從這一點說他們可以說是一個東西。這就相當於我們看到饅頭和麪條一樣，表面上看他們不一樣（注意僅僅是表面）但是他們核心是一致的，都是面……
知識的學習過程就要像老牛反芻一樣，需要不斷的加深認識，最終才能真正領悟
對事物的認識是從感性到理性的，是一步一步的加深的，每一步的加深也許會推翻以前的自己，也許會更加贊同以前的自己。如果是推翻以前的自己那麼代表對這個事物的認識發生了翻天地覆的變化，但是如果讚許以前的自己也並不代表自己的觀點沒有變化，往往表面上看起來一致的東西其實內核並一定是相同的。就像剛開始的時候認爲三層架構和MVC是一個東西到最後同樣是認爲這兩是一個東西，但是理解的層次絕對是不一樣的。
至於以後會不會再次推翻自己的觀點我不曉得，只能說每次推翻都代表着進步，代表着理解的更深一層，所以我期望着下次的否定自己
http://baike.baidu.com/view/687468.htm
與MVC的區別 MVC（模型Model-視圖View-控制器Controller）是一種設計模式，我們可以用它來創建在域對象和UI表示層對象之間的區分。
同樣是架構級別的，相同的地方在於他們都有一個表現層，但是他們不同的地方在於其他的兩個層。
在三層架構中沒有定義Controller的概念。這是我認爲最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。
http://topic.csdn.net/u/20090710/14/07f4447d-60c4-4b74-af1c-ea1b6e2e9ca7.html
當然啊，你要明白三層架構的MVC的區別和聯繫：
三層架構是最基本的項目分層結果，而MVC則是三層架構的一個變體，MVC是一種好的開發模式。首先你要明白MVC分別代表的是什麼意思.
M 即Model(模型層)，主要負責出來業務邏輯以及數據庫的交互
V 即View(視圖層)，主要用於顯示數據和提交數據
C 即Controller(控制器)，主要是用作捕獲請求並控制請求轉發
三層:UI 界面層 BLL 業務邏輯層，DAL數據訪問層，Model 實體層
MVC中的的M 不是三層中的Model(實體層)，他其實包括三層中的 BLL，DAL,Model,這是非常要注意的，這也是他們之間的區別的關鍵所在
其有點有如下：
低耦合性
高重用性和可適用性
較低的生命週期成本
快速的部署
可維護性
有利於軟件工程化管理
當然優點也有缺點，那就是內部結構複雜，不容易理解，文件數量大，管理難度自然也就大
三層架構…
他們細分之後得到的是：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller
MVC把 BIZ（BLL）、DAO（DAL）、Model（Entity） 統一稱之爲 模型(MODEL)，得到：View、Controller、模型(MODEL)
三層 在我使用中 暫未體會到控制器的存在，完全是：UI、DAO、BLL
他們相同的設計理念就是：把視圖設計與數據持久化進行分離，從而降低耦合性，易於擴展，提高團隊開發效率。
三層是基於業務邏輯來分的，而mvc是基於頁面來分的
根本就沒有什麼可比性。
其實兩個一起用我感覺很好
MVC模式是一種複合設計模式，一種解決方案
三層是種軟件架構，通過接口實現編程
三層模式是體系結構模式，MVC是設計模式
三層模式又可歸於部署模式，MVC可歸於表示模式
沒有什麼取捨的，說的根本不是一回事。在所謂的“三層”中，它要求你將BLL層獨立出來，它只是告訴你表示層和業務邏輯層之間的靜態關係。而MVC則告訴你在這個具體的地方如何處理其動態驅動流程，儘管mvc仍然粗糙（甚至mvp也是粗糙的），但是已經比所謂三層更細緻一些了。
謝謝大家的關注，這幾天都在忙面試，沒來結貼。再次謝謝大家。
我大概明白了：三層架構和mvc設計模式側重點不一樣，三層是一種籠統的架構思想，沒有限制具體的設計；而mvc就比較具體的說明它的設計方法。
還是自己動手做一下，理解會更深一些，以前都是用三層架構的方法
---------------------------------------------------------------------------------------------------------------
http://apps.hi.baidu.com/share/detail/15057889
ASP.NET MVC 與 WebForm 三層架構 區別
1.傳統WebForm開發中存在的一些問題
傳統的ASP.NET開發中，微軟的開發團隊爲開發者設計了一個在可視化設計器中拖放控件，編寫代碼響應事件的快速開發環境。然而，它所帶來的負面效應是：
由於控件封裝了很多東西，開發者很難了解這背後的HTML是如何運作的
容易得到一個包含大量ViewState的頁面，使得頁面尺寸遠遠超過所需的內容，使得頁面的打開速度較慢
不容易被測試
2.什麼是MVC?
MVC（Model-View-Controller，模型-視圖-控制器模式）是軟件工程中的一種軟件架構模式。它把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。
3.什麼是ASP.NET MVC?
ASP.NET MVC是微軟的開發團隊基於MVC開發的一個易於被測試的框架。它具有以下特性：
沒有數據回傳
沒有在頁面中保存視圖狀態
開發者可以完全掌控頁面的呈現過程
易於單元測試
易於測試驅動開發
可擴展、可替換
支持WebForm中的有關特性，如：用戶控件、母版頁、數據綁定、本地化等
不在基於文件目錄結構，而是將URL映射到控制器中
4. 爲什麼使用ASP.NET MVC?
易於進行單元測試
易於進行測試驅動開發
避免了WebForm中大量的ViewState導致頁面文件變得臃腫
5. MVC與三層架構?
MVC是一種模式
ASP.NET MVC是一個基於MVC模式的開發框架
三層架構是一種架構
至於區別，可以嚴格的從概念上區分開來。
下圖是MVC與三層架構的對應關係
6. MVC與Webform如何抉擇?
7. 兩種技術並存
ASP.NET MVC框架只是給開發者提供歐諾個了開發web應用程序的一種選擇，並不是要取代Webform
這兩種技術各有優缺點，開發者需要根據實際情況，選擇對應的技術
有時候，可以在同一個項目中混合使用這兩種技術
8.ASP.NET MVC與Webform技術的架構圖
總結：
看完本文，相信ASP.NET WebForm與ASP.NET MVC的選擇相信大家應該可以做到心中有數了，我始終覺得，很多時候並不是什麼技術好不好的問題，而是適合不適合不適合的問題或者能否把它用好的問題。
打個比方：如果讓千里馬犁地，恐怕未必能達到理想的效果，最終可能還會抱怨，什麼破馬，一點勁都沒有。
========================================================================
http://www.blogjava.net/phyeas/archive/2008/07/01/211995.html
同樣是架構級別的，它們有什麼相同點和不同點呢？這篇文章討論一下它們的異同點。希望能幫助讀者理解其中的玄機。 :)
其實它們相同的地方在於他們都有一個表現層。
但是他們不同的地方在於其他的兩個層。
首先先解釋一下MVC。V即View.是視圖的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。這三個裏.最不容易理解的應該是Model.就是什麼是Model，而爲什麼叫Model。我先不說爲什麼叫Model，先解釋Controler。
Controller是控制器的意思，所謂控制器，就是將用戶請求轉發給模型層，經過處理後把結果返回到界面展現的一箇中間層，那麼Controler到底管什麼工作呢？先不說.先來看下在Java Web中這三個層一般的定義，一般在Java Web裏，JSP充當V，Servlet充當C,JavaBean充當M，這裏的Servlet管什麼工作呢？接受輸入，轉到Model層去處理，處理結果保存後轉發到JSP，然後展現數據。所以它的功能就是控制器的基本功能，它就管轉發，在V和M之間轉來轉去。
再來說說M，即Model，在Java Web裏說的是JavaBean，我認識的很多人都把JavaBean誤認爲是實體類，其實JavaBean有比實體類更豐富的定義，在JavaBean中除了其屬性和字段，還可以有行爲及其事件，JavaBean可以理解爲普通Java對象。Java普通對象，就是符合Java規範的所有對象，這和實體類完全是兩回事。所以，我認爲在MVC中。業務邏輯和數據訪問應該放在Model層，也就是V負責展示數據，Controler除了轉發不做業務邏輯。真正的邏輯事務，數據訪問，甚至算法都放到Model去。
再說三層架構。三層其實很好理解，界面，業務，數據訪問，就這三個，從字面都可以理解出它們的意思。我要說的是它和MVC的區別。在三層架構中沒有定義Controler的概念。這是我認爲最不同的地方。而MVC也沒有把業務的邏輯訪問看成兩個層，這是採用三層架構或MVC搭建程序最主要的區別。
當然了。在三層中也提到了Model，但是三層架構中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是已實體類構成的，而MVC裏，則是由業務邏輯與訪問數據組成的。不一樣的概念。雖然名字一樣。
http://blog.sina.com.cn/s/blog_677b66170100mv16.html
asp.net mvc和三層架構聯繫與區別
首先,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 是微軟在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模式可以較爲隨意。
