又看到有人在問三層架構(gòu)和MVC的關(guān)系，感覺這種問題有點教條化了。因為它們都在邏輯上將應(yīng)用程序劃為三塊，湊了一個數(shù)字3，就有人非要把它們聯(lián)系到一起了。

這兩個東西我接觸有幾年了，有一點體會，表達(dá)一下：

三層是三層，MVC是MVC，它們毫無關(guān)系的。

三層

是從整個應(yīng)用程序架構(gòu)的角度來分的三層（如果程序需要，還可以分多層）。

三層是為了解決整個應(yīng)用程序中各個業(yè)務(wù)操作過程中不同階段的代碼封裝的問題，為了使程序員更加專注的處理某階段的業(yè)務(wù)邏輯。

比如將數(shù)據(jù)庫操作代碼封裝到一層中，提供一些方法根據(jù)參數(shù)直接返回用戶需要的相應(yīng)數(shù)據(jù)，這樣在處理具體的業(yè)務(wù)邏輯的時候，就不用關(guān)心數(shù)據(jù)的存儲問題了。

MVC

是在應(yīng)用程序（BS結(jié)構(gòu)）的視圖層劃分出來的不同功能的幾個模塊。

MVC主要是為了解決應(yīng)用程序用戶界面的樣式替換問題，把展示數(shù)據(jù)的 HTML 頁面盡可能的和業(yè)務(wù)代碼分離。MVC把純凈的界面展示邏輯（用戶界面）獨立到一些文件中（Views），把一些和用戶交互的程序邏輯（Controller）單獨放在一些文件中，在 Views 和 Controller 中傳遞數(shù)據(jù)使用一些專門封裝數(shù)據(jù)的實體對象，這些對象，統(tǒng)稱為Models。

只所以說MVC和三層毫無關(guān)系，是因為它們二者使用范圍不同：三層可以應(yīng)用于任何語言、任何技術(shù)的應(yīng)用程序；而MVC只是為了解決BS應(yīng)用程序視圖層各部分的耦合關(guān)系。它們互不沖突，可以同時存在，也可根據(jù)情況使用其中一種。

http://blog.csdn.net/beijiguangyong/article/details/7029257

三層架構(gòu)就是MVC！

起初老師總說三層MVC，MVC三層架構(gòu)……

所以開始的時候腦子就一個概念：三層就是MVC，MVC就是三層架構(gòu)。而且想想也合理啊，都是“三”。MVC是三個字母，三層架構(gòu)也是“三”，理所應(yīng)當(dāng)?shù)木蛯?yīng)上了。然后就這么一直“錯”了很長時間。

三層架構(gòu)絕不是MVC??！

后來學(xué)習(xí)了J2EE之后發(fā)現(xiàn)老師說的好像不對，MVC和三層架構(gòu)不是一個東西。三層架構(gòu)是界面層（UI）業(yè)務(wù)邏輯層（BLL）和數(shù)據(jù)訪問層（DAL）構(gòu)成的，而MVC是模型層（M）界面層（View）和控制層（Controller）構(gòu)成的，而且他們之間也不對應(yīng)。

如果硬要給他們對應(yīng)的話，那么三層架構(gòu)中的UI對應(yīng)MVC中的view（jsp），都是用于顯示以及獲取界面的數(shù)據(jù)；三層架構(gòu)中的BLL層和DAL層對應(yīng)MVC中的Model（javabean）層都是用于處理上層傳遞來的數(shù)據(jù)以及從數(shù)據(jù)庫獲取的數(shù)據(jù)的；MVC中的Controller（Servlet）最多算是三層架構(gòu)中的UI的一部分，也就我們常說的是Servlet。

如下圖所示：

[圖片上傳失敗...(image-74a78a-1513862924180)]

頓時感到世界明朗了，對分層又深入了解了一步。

其實三層架構(gòu)和MVC還是一個東西?。?！

這幾天一直在思考三層架構(gòu)和MVC到底是個什么關(guān)系，老師為什么起初會放在一起說嘞？然后恍然大悟：其實三層架構(gòu)和MVC是一樣的?。。∥覀兯吹降牟灰粯又皇潜砻嫔系牟灰粯?。核心的東西是一致的，那么什么是核心？

答曰：分層，解耦！

如果從解耦的角度來看三層架構(gòu)和MVC其實他們是一致的，只不過劃分的方法不一樣罷了，就像上面的圖所示。從這一點說他們可以說是一個東西。這就相當(dāng)于我們看到饅頭和面條一樣，表面上看他們不一樣（注意僅僅是表面）但是他們核心是一致的，都是面……

知識的學(xué)習(xí)過程就要像老牛反芻一樣，需要不斷的加深認(rèn)識，最終才能真正領(lǐng)悟

對事物的認(rèn)識是從感性到理性的，是一步一步的加深的，每一步的加深也許會推翻以前的自己，也許會更加贊同以前的自己。如果是推翻以前的自己那么代表對這個事物的認(rèn)識發(fā)生了翻天地覆的變化，但是如果贊許以前的自己也并不代表自己的觀點沒有變化，往往表面上看起來一致的東西其實內(nèi)核并一定是相同的。就像剛開始的時候認(rèn)為三層架構(gòu)和MVC是一個東西到最后同樣是認(rèn)為這兩是一個東西，但是理解的層次絕對是不一樣的。

至于以后會不會再次推翻自己的觀點我不曉得，只能說每次推翻都代表著進(jìn)步，代表著理解的更深一層，所以我期望著下次的否定自己

http://baike.baidu.com/view/687468.htm

與MVC的區(qū)別

MVC（模型Model-視圖View-控制器Controller）是一種設(shè)計模式，我們可以用它來創(chuàng)建在域?qū)ο蠛蚒I表示層對象之間的區(qū)分。

同樣是架構(gòu)級別的，相同的地方在于他們都有一個表現(xiàn)層，但是他們不同的地方在于其他的兩個層。

在三層架構(gòu)中沒有定義Controller的概念。這是我認(rèn)為最不同的地方。而MVC也沒有把業(yè)務(wù)的邏輯訪問看成兩個層，這是采用三層架構(gòu)或MVC搭建程序最主要的區(qū)別。當(dāng)然了。在三層中也提到了Model，但是三層架構(gòu)中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是以實體類構(gòu)成的，而MVC里，則是由業(yè)務(wù)邏輯與訪問數(shù)據(jù)組成的。

http://topic.csdn.net/u/20090710/14/07f4447d-60c4-4b74-af1c-ea1b6e2e9ca7.html

當(dāng)然啊，你要明白三層架構(gòu)的MVC的區(qū)別和聯(lián)系：

三層架構(gòu)是最基本的項目分層結(jié)果，而MVC則是三層架構(gòu)的一個變體，MVC是一種好的開發(fā)模式。首先你要明白MVC分別代表的是什么意思.
M 即Model(模型層)，主要負(fù)責(zé)出來業(yè)務(wù)邏輯以及數(shù)據(jù)庫的交互
V 即View(視圖層)，主要用于顯示數(shù)據(jù)和提交數(shù)據(jù)
C 即Controller(控制器)，主要是用作捕獲請求并控制請求轉(zhuǎn)發(fā)

三層:UI 界面層 BLL 業(yè)務(wù)邏輯層，DAL數(shù)據(jù)訪問層，Model 實體層
MVC中的的M 不是三層中的Model(實體層)，他其實包括三層中的 BLL，DAL,Model,這是非常要注意的，這也是他們之間的區(qū)別的關(guān)鍵所在

其有點有如下：
低耦合性
高重用性和可適用性
較低的生命周期成本
快速的部署
可維護(hù)性
有利于軟件工程化管理

當(dāng)然優(yōu)點也有缺點，那就是內(nèi)部結(jié)構(gòu)復(fù)雜，不容易理解，文件數(shù)量大，管理難度自然也就大

MVC設(shè)計模式…
三層架構(gòu)…
他們細(xì)分之后得到的是：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller
MVC把 BIZ（BLL）、DAO（DAL）、Model（Entity） 統(tǒng)一稱之為

模型(MODEL)

，得到：View、Controller、

模型(MODEL)

三層 在我使用中 暫未體會到控制器的存在，完全是：UI、DAO、BLL

他們相同的設(shè)計理念就是：把視圖設(shè)計與數(shù)據(jù)持久化進(jìn)行分離，從而降低耦合性，易于擴展，提高團隊開發(fā)效率。

三層是基于業(yè)務(wù)邏輯來分的，而mvc是基于頁面來分的
根本就沒有什么可比性。
其實兩個一起用我感覺很好

MVC模式是一種復(fù)合設(shè)計模式，一種解決方案
三層是種軟件架構(gòu)，通過接口實現(xiàn)編程
三層模式是體系結(jié)構(gòu)模式，MVC是設(shè)計模式
三層模式又可歸于部署模式，MVC可歸于表示模式
還是自己動手做一下，理解會更深一些，以前都是用三層架構(gòu)的方法

http://apps.hi.baidu.com/share/detail/15057889

ASP.NET MVC 與 WebForm 三層架構(gòu) 區(qū)別

1.傳統(tǒng)WebForm開發(fā)中存在的一些問題

傳統(tǒng)的ASP.NET開發(fā)中，微軟的開發(fā)團隊為開發(fā)者設(shè)計了一個在可視化設(shè)計器中拖放控件，編寫代碼響應(yīng)事件的快速開發(fā)環(huán)境。然而，它所帶來的負(fù)面效應(yīng)是：

由于控件封裝了很多東西，開發(fā)者很難了解這背后的HTML是如何運作的

容易得到一個包含大量ViewState的頁面，使得頁面尺寸遠(yuǎn)遠(yuǎn)超過所需的內(nèi)容，使得頁面的打開速度較慢

不容易被測試

2.什么是MVC?

MVC（Model-View-Controller，模型-視圖-控制器模式）是軟件工程中的一種軟件架構(gòu)模式。它把軟件系統(tǒng)分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

3.什么是ASP.NET MVC?

ASP.NET MVC是微軟的開發(fā)團隊基于MVC開發(fā)的一個易于被測試的框架。它具有以下特性：

沒有數(shù)據(jù)回傳

沒有在頁面中保存視圖狀態(tài)

開發(fā)者可以完全掌控頁面的呈現(xiàn)過程

易于單元測試

易于測試驅(qū)動開發(fā)

可擴展、可替換

支持WebForm中的有關(guān)特性，如：用戶控件、母版頁、數(shù)據(jù)綁定、本地化等

不在基于文件目錄結(jié)構(gòu)，而是將URL映射到控制器中

為什么使用ASP.NET MVC?

易于進(jìn)行單元測試

易于進(jìn)行測試驅(qū)動開發(fā)

避免了WebForm中大量的ViewState導(dǎo)致頁面文件變得臃腫

5. MVC與三層架構(gòu) ?

MVC是一種模式
ASP.NET MVC是一個基于MVC模式的開發(fā)框架
三層架構(gòu)是一種架構(gòu)

至于區(qū)別，可以嚴(yán)格的從概念上區(qū)分開來。

下圖是MVC與三層架構(gòu)的對應(yīng)關(guān)系

[圖片上傳失敗...(image-dbd26f-1513862965881)]

6. MVC與Webform如何抉擇?

[圖片上傳失敗...(image-8065dc-1513862965881)]

7. 兩種技術(shù)并存

ASP.NET MVC框架只是給開發(fā)者提供歐諾個了開發(fā)web應(yīng)用程序的一種選擇，并不是要取代Webform

這兩種技術(shù)各有優(yōu)缺點，開發(fā)者需要根據(jù)實際情況，選擇對應(yīng)的技術(shù)

有時候，可以在同一個項目中混合使用這兩種技術(shù)

8.ASP.NET MVC與Webform技術(shù)的架構(gòu)圖

[圖片上傳失敗...(image-e4ecd3-1513862965881)]

總結(jié)：

看完本文，相信ASP.NET WebForm與ASP.NET MVC的選擇相信大家應(yīng)該可以做到心中有數(shù)了，我始終覺得，很多時候并不是什么技術(shù)好不好的問題，而是適合不適合不適合的問題或者能否把它用好的問題。

打個比方：如果讓千里馬犁地，恐怕未必能達(dá)到理想的效果，最終可能還會抱怨，什么破馬，一點勁都沒有。

========================================================================

http://www.blogjava.net/phyeas/archive/2008/07/01/211995.html

同樣是架構(gòu)級別的，它們有什么相同點和不同點呢？這篇文章討論一下它們的異同點。希望能幫助讀者理解其中的玄機。 :)

其實它們相同的地方在于他們都有一個表現(xiàn)層。

但是他們不同的地方在于其他的兩個層。

首先先解釋一下MVC。V即View.是視圖的意思。C即Controler.是控制器的意思。而M即Model，是模型的意思。這三個里.最不容易理解的應(yīng)該是Model.就是什么是Model，而為什么叫Model。我先不說為什么叫Model，先解釋Controler。

Controller

是控制器的意思，所謂控制器，就是將用戶請求轉(zhuǎn)發(fā)給模型層，經(jīng)過處理后把結(jié)果返回到界面展現(xiàn)的一個中間層，那么Controler到底管什么工作呢？先不說.先來看下在Java Web中這三個層一般的定義，一般在Java Web里，JSP充當(dāng)V，Servlet充當(dāng)C,JavaBean充當(dāng)M，這里的Servlet管什么工作呢？接受輸入，轉(zhuǎn)到Model層去處理，處理結(jié)果保存后轉(zhuǎn)發(fā)到JSP，然后展現(xiàn)數(shù)據(jù)。所以它的功能就是控制器的基本功能，它就管轉(zhuǎn)發(fā)，在V和M之間轉(zhuǎn)來轉(zhuǎn)去。

再來說說M，即Model，在Java Web里說的是JavaBean，我認(rèn)識的很多人都把JavaBean誤認(rèn)為是實體類，其實JavaBean有比實體類更豐富的定義，在JavaBean中除了其屬性和字段，還可以有行為及其事件，JavaBean可以理解為普通Java對象。Java普通對象，就是符合Java規(guī)范的所有對象，這和實體類完全是兩回事。所以，我認(rèn)為在MVC中。業(yè)務(wù)邏輯和數(shù)據(jù)訪問應(yīng)該放在Model層，也就是V負(fù)責(zé)展示數(shù)據(jù)，Controler除了轉(zhuǎn)發(fā)不做業(yè)務(wù)邏輯。真正的邏輯事務(wù)，數(shù)據(jù)訪問，甚至算法都放到Model去。

再說三層架構(gòu)。三層其實很好理解，界面，業(yè)務(wù)，數(shù)據(jù)訪問，就這三個，從字面都可以理解出它們的意思。我要說的是它和MVC的區(qū)別。在三層架構(gòu)中沒有定義Controler的概念。這是我認(rèn)為最不同的地方。而MVC也沒有把業(yè)務(wù)的邏輯訪問看成兩個層，這是采用三層架構(gòu)或MVC搭建程序最主要的區(qū)別。

當(dāng)然了。在三層中也提到了Model，但是三層架構(gòu)中Model的概念與MVC中Model的概念是不一樣的，“三層”中典型的Model層是已實體類構(gòu)成的，而MVC里，則是由業(yè)務(wù)邏輯與訪問數(shù)據(jù)組成的。不一樣的概念。雖然名字一樣。

http://blog.sina.com.cn/s/blog_677b66170100mv16.html

asp.net mvc和三層架構(gòu)聯(lián)系與區(qū)別

首先,MVC和三層架構(gòu)，是不一樣的。
　　三層架構(gòu)中，DAL(數(shù)據(jù)訪問層)、BLL(業(yè)務(wù)邏輯層)、WEB層各司其職，意在職責(zé)分離。
　　MVC是 Model-View-Controller，嚴(yán)格說這三個加起來以后才是三層架構(gòu)中的WEB層，也就是說，MVC把三層架構(gòu)中的WEB層再度進(jìn)行了分化，分成了控制器、視圖、實體三個部分，控制器完成頁面邏輯，通過實體來與界面層完成通話；而C層直接與三層中的BLL進(jìn)行對話。
　　所以，

.net的三層結(jié)構(gòu)中，并沒有action這個概念。
　　asp.net mvc

是微軟新發(fā)布的一種網(wǎng)站開發(fā)架構(gòu)。為了解決傳統(tǒng)asp.net開發(fā)中不能分離Model,View和Controller而設(shè)計的。
　　普通的網(wǎng)站為了解決可移植，可維護(hù)，可擴展等問題，會把網(wǎng)站設(shè)計成三個獨立的模塊，Model負(fù)責(zé)數(shù)據(jù)庫部分，View負(fù)責(zé)網(wǎng)頁的界面，而Controller負(fù)責(zé)界面與數(shù)據(jù)的交互及業(yè)務(wù)邏輯，這樣設(shè)計的網(wǎng)站如果想設(shè)計或者重新開發(fā)某一個模塊對其他的模塊是沒有影響的。但是asp.net的頁面后臺代碼與每個頁面代碼都是一一對應(yīng)的，業(yè)務(wù)邏輯在某些情況下不可避免的被寫到了與View關(guān)聯(lián)的后臺代碼中。這樣就不能保證View與Controller的分離，也就很難實現(xiàn)網(wǎng)站的重寫和升級。
　　而在MVC中頁面代碼并不是與后臺代碼一一對應(yīng)，而是分別被存放成Controller和View兩個部分，徹底的解決了，View和Controller不能獨立的問題。從而改善網(wǎng)站的重寫和升級過程。
　　但是MVC也有其缺點，由于在頁面代碼中不再可以使用服務(wù)器控件，因此給某些asp.net服務(wù)器端控件的使用帶來了麻煩，而且MVC也頁面的設(shè)計工作帶來了很多障礙。
　　ASP.NET MVC

是微軟在2009年4月份發(fā)布的一種新的網(wǎng)站開發(fā)架構(gòu)，http://msdn.microsoft.com/en-us/library/dd394709.a spx，它是把傳統(tǒng)意義上的MVC開發(fā)思想融合到了ASP.NET的開發(fā)當(dāng)中。
　　那么我也來講講我對這兩者的理解吧。
　　首先對這個題目，本身是存在問題的，"XX結(jié)構(gòu)"與"XX模式"的區(qū)別？請問中國社會制度與美國人生活方式有什么區(qū)別？
　　這兩者本身講的是不同方向與角度的問題，在實際應(yīng)用中他們的確存在一些相似的特點，在很多書籍中也沒有深入講解，以致于造成困惑，為了更好的理解他們，姑且來說說區(qū)別吧。
　　首先N層結(jié)構(gòu)是一種軟件抽象的層次結(jié)構(gòu)，是對復(fù)雜軟件的一種縱向切分，每一層次中完成同一類型的操作，以便將各種代碼以其完成的使命作為依據(jù)來分割，以將低軟件的復(fù)雜度，提高其可維護(hù)性。一般來說，層次之間是向下依賴的，下層代碼未確定其接口（契約）前，上層代碼是無法開發(fā)的，下層代碼接口（契約）的變化將使上層的代碼一起變化。三層結(jié)構(gòu)是N層結(jié)構(gòu)的一種，是人產(chǎn)在長時間使用中得出來的一種應(yīng)用場合廣泛的N層結(jié)構(gòu)，被當(dāng)作一種典型的軟件層次結(jié)構(gòu)而廣為流傳甚至寫入教科書。
　　MVC模式是一種復(fù)合設(shè)計模式，一種在特定場合用于解決某種實際問題來得出的可以反復(fù)實踐的解決方案。巧合的是他也有三個事物組成，于是乎人們就有了一種想當(dāng)然的對應(yīng)關(guān)系：展示層-View；業(yè)務(wù)邏輯層-Control；持久層-Model。首先MVC中的三個事物之間并不存在明顯的層次結(jié)構(gòu)，沒有明顯的向下依賴關(guān)系，相反的，View和Model往往是比較獨立的，而Control是連接兩者的橋梁，他們更像是橫向的切分。這樣一來就出現(xiàn)一個結(jié)果，MVC中每個塊都是可以獨立測試的，而三層結(jié)構(gòu)中，上層模塊的運行測試勢必要提供下層代碼或者提供相同接口的樁。相對來說，MVC復(fù)雜得多，但是結(jié)構(gòu)更清晰，耦合性更低。
　　另外，MVC中每一塊內(nèi)部特別是Model內(nèi)部經(jīng)常被設(shè)計為多層的。在我認(rèn)為的一個良好的MVC模式構(gòu)建的結(jié)構(gòu)中，Control是核心，小且較為穩(wěn)定的，可以作為一個核心框架來提供，有擴展點，但基本上可以簡單配置不需要任何代碼就可以運行。而View則可能是一套或多種可選擇的視圖引擎，決定了軟件展示給用于的界面，使用時的主要工作量在于擴展點以及根據(jù)需要而數(shù)量不同的視圖模板。Model則是業(yè)務(wù)提供者，決定了軟件提供的功能，其內(nèi)部可能是一些普通的類或者是實現(xiàn)了某些接口的類，在這一塊當(dāng)中可能根據(jù)業(yè)務(wù)的不同而色彩繽紛，對于復(fù)雜的軟件可能會分成很多層，如業(yè)務(wù)邏輯層、業(yè)務(wù)提供層、系統(tǒng)提供層、數(shù)據(jù)提供層、數(shù)據(jù)訪問層等。
　　我經(jīng)常用于比喻MVC的例子是小時候玩的那種卡帶式游戲機，Control是主機，一般來說我買一個主機就行了，只要他不壞，他就能一直讓我玩這一類的游戲。View則是電視機和游戲手柄，電視機可以獨立工作，他不管輸入的是電視信號、影碟機信號還是游戲機信號，他只管顯示，而且他決定了我們看到的效果是怎么樣的，如果我想要個尺寸更大的或者彩色的顯示效果，我只需要買個相應(yīng)的電視機就行了，手柄也是可以換的，要遙桿還是帶震動的。Model則是游戲卡帶，他絕定了我玩的是什么游戲，是魂斗羅還是超級瑪莉，而且游戲機主機和電視機生產(chǎn)廠家永遠(yuǎn)也不知道在上面有可能會運行什么樣的游戲?？◣е锌赡軙杏螒虼a和存儲單元，都根據(jù)游戲的需要而設(shè)計。
　　有朋友提到游戲主機提供的卡帶插槽的接口，在設(shè)計中，有時也由Control提供一組接口，以用于Model或View的實現(xiàn)，這樣就形成了依賴。一般來說這樣設(shè)計也沒有太大的問題，只是會提高模塊間的耦合度，也會帶來一些侵入性。為了更完美，可以不用接口來提供契約，可以用配置信息（或稱元數(shù)據(jù)信息）+反射來提供契約，那么這個類接口就可以退化到只要符合CLS就可以了，也就是普通的類，就像現(xiàn)在的計算機接口廣泛采用USB，無論是U盤、打印機、掃描儀或者是加密狗，他們都是普通的USB設(shè)備而已。
　　提到USB有一個題外話，模塊的可插拔性設(shè)計甚至是熱插拔設(shè)計，系統(tǒng)可以在不停止運行的情況下動態(tài)的掛載或移除模塊，動態(tài)掛載模塊需要系統(tǒng)能夠自動發(fā)現(xiàn)新模塊并根據(jù)自描述的信息進(jìn)行自動配置，移除可能情況更復(fù)雜一點，需要"安全刪除硬件"類似的功能。
　　在設(shè)計廣泛重用的框架時會考慮多種情況以達(dá)到更大的適應(yīng)性，一般項目中應(yīng)用MVC模式可以較為隨意。