Web項目的三層架構和MVC架構異同

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,這是很是要注意的，這也是他們之間的區別的關鍵所在
其有點有以下： 低耦合性 高重用性和可適用性 較低的生命週期成本 快速的部署 可維護性 有利於軟件工程化管理
固然優勢也有缺點，那就是內部結構複雜，不容易理解，文件數量大，管理難度天然也就大

 

 

MVC設計模式… 三層架構… 他們細分以後獲得的是：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可歸於表示模式

 

引用樓主 daijun17 的回覆:

如何在三層架構和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模式能夠較爲隨意。