1、簡介

MVC是一種架構設計模式，是一種設計理念。是為了達到分層設計的目的，從而使代碼解耦，便於維護和代碼的復用。MVC是3個單詞的縮寫，全稱：Model-View-Controller（模型-視圖-控制器）。

Model：

Model在MVC中扮演著功能掌控者的角色，屬於底層，它處理業務邏輯和數據模型，例如User selectUser（）；這個方法和它調用之後返回的Bean都是屬於Model的。至於以何種方式把User傳遞到前臺（例如以Bean的方式傳遞，使用JSP標簽進行處理；或者使用Json格式進行傳遞，在前臺使用JS語言進行處理），可以自由選擇。

View：

View在MVC中扮演這展示者的角色，屬於上層，它展示從底層提取出來的數據（如以表格，圖表等方式），在Jsp中是以Jsp標簽進行展示，在其它前臺框架中是用Json格式進行數據的處理（在Spring中@controller返回的是JavaBean，@RESTcontroller返回的是Json格式的數據）。

Controller：

Controller在MVC中扮演的是路由控制的角色，屬於中間層，它處理用戶通過前端發送過來的請求（當然其它MV*模式可能不通過Controller直接向Model發送請求），並調用底層中的對應的方法進行數據的請求，然後將數據發送出去。

2、實例

MVC 主要的框架有 Spring Struts ZF .NET

以SpringMVC為例來解釋下MVC在spring的工作流程中如何體現的

springMVC是一個MVC的開源框架，springMVC=struts2+spring，springMVC就相當於是Struts2加上sring的整合，但是這裏有一個疑惑就是，springMVC和spring是什麽樣的關系呢？這個在百度百科上有一個很好的解釋：意思是說，springMVC是spring的一個後續產品，其實就是spring在原有基礎上，又提供了web應用的MVC模塊，可以簡單的把springMVC理解為是spring的一個模塊（類似AOP，IOC這樣的模塊），網絡上經常會說springMVC和spring無縫集成，其實springMVC就是spring的一個子模塊，所以根本不需要同spring進行整合。

這張圖中將前端的視圖用jsp來代替，Dao是MVC外的另一個層數據持久層，主要進行對數據庫的操作。

SpringMVC的工作流程就是

第一步:用戶發起請求到前端控制器（DispatcherServlet）

第二步：前端控制器請求處理器映射器（HandlerMappering）去查找處理器（Handle）：通過xml配置或者註解進行查找

第三步：找到以後處理器映射器（HandlerMappering）像前端控制器返回執行鏈（HandlerExecutionChain）

第四步：前端控制器（DispatcherServlet）調用處理器適配器（HandlerAdapter）去執行處理器（Handler）

第五步：處理器適配器去執行Handler

第六步：Handler執行完給處理器適配器返回ModelAndView

第七步：處理器適配器向前端控制器返回ModelAndView

第八步：前端控制器請求視圖解析器（ViewResolver）去進行視圖解析

第九步：視圖解析器像前端控制器返回View

第十步：前端控制器對視圖進行渲染

第十一步：前端控制器向用戶響應結果

　例如①，小時候玩的那種卡帶式遊戲機，Control是主機，一般來說我買一個主機就行了，只要他不壞，他就能一直讓我玩這一類的遊戲。View則是電視機和遊戲手柄，電視機可以獨立工作，他不管輸入的是電視信號、影碟機信號還是遊戲機信號，他只管顯示，而且他決定了我們看到的效果是怎麽樣的，如果我想要個尺寸更大的或者彩色的顯示效果，我只需要買個相應的電視機就行了，手柄也是可以換的，遙桿還是帶震動的。Model則是遊戲卡帶，他決定了我玩的是什麽遊戲，是魂鬥羅還是超級瑪莉，而且遊戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什麽樣的遊戲。卡帶中可能會有遊戲代碼和存儲單元，都根據遊戲的需要而設計。

　　例如②，一個采用比例表示的用於政治選舉的一個簡單信息系統，它提供了一個輸入數據的電子數據表和表示當前結果的幾種圖標。用戶可以通過圖形接口與系統交互。所有信息顯示必須立即反應出選舉數據的變化。（引用自《面向模式的軟件體系結構-卷1 模式系統》）

　　即，一旦模型的數據發生了變化，模型要通報所有的視圖。

3、存在的問題

因為在PHP還不支持面向對象之前，是過程化的方式來創建的，它們將 Model View Controller 三層的代碼混在一起，十分混亂。所以它解決的問題有：維護難，開發速度慢，二次開發難度高，工作量大，代碼復用，耦合度高，系統不靈活。

4、 MVC架構的優缺點

優點：

耦合性低

視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。

重用性高

MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因為多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。

生命周期成本低

MVC使開發和維護用戶接口的技術含量降低。

部署快

使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。

可維護性高

分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。

有利軟件工程化管理

由於不同的層各司其職，每一層不同的應用具有某些相同的特征，有利於通過工程化、工具化管理程序代碼。控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。

缺點：

沒有明確的定義

完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較復雜，所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。

不適合小型，中等規模的應用程序

花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失。

增加系統結構和實現的復雜性

對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。

視圖與控制器間的過於緊密的連接

視圖與控制器是相互分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。

視圖對模型數據的低效率訪問

依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。

一般高級的界面工具或構造器不支持模式

改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，會造成MVC使用的困難。

MVC架構之二