MVC簡介

MVC模式（Model–view–controller）是軟件工程中的一種軟件架構模式，把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。

MVC模式最先由TrygveReenskaug在1978年提出，是施樂帕羅奧多研究中心（Xerox PARC）在20世紀80年代爲程序語言Smalltalk發明的一種軟件架構。的目的是實現一種動態的程序設計，使後續對程序的修改和擴展簡化，而且使程序某一部分的重複利用成爲可能。除此以外，此模式經過對複雜度的簡化，使程序結構更加直觀。軟件系統經過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員能夠經過自身的專長分組：

• 控制器（Controller）- 負責轉發請求，對請求進行處理。
• 視圖（View） - 界面設計人員進行圖形界面設計。
• 模型（Model） - 程序員編寫程序應有的功能（實現算法等等）、數據庫專家進行數據管理和數據庫設計(能夠實現具體的功能)

將應用程序劃分爲三種組件，模型 - 視圖 - 控制器（MVC）設計定義它們之間的相互做用。模型用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。「 Model 」有對數據直接訪問的權力，例如對數據庫的訪問。「Model」不依賴「View」和「Controller」，也就是說， Model 不關心它會被如何顯示或是如何被操做。可是 Model 中數據的變化通常會經過一種刷新機制被公佈。爲了實現這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，從而，View 能夠了解在數據 Model 上發生的改變。視圖(View)可以實現數據有目的的顯示（理論上，這不是必需的）。在 View 中通常沒有程序上的邏輯。爲了實現 View 上的刷新功能，View 須要訪問它監視的數據模型（Model），所以應該事先在被它監視的數據那裏註冊。

• 控制器（Controller）起到不一樣層面間的組織做用，用於控制應用程序的流程。它處理事件並做出響應。「事件」包括用戶的行爲和數據 Model 上的改變。

• 在最初的JSP網頁中，像數據庫查詢語句(SQL query)這樣的數據層代碼和像HTML這樣的表示層代碼是混在一塊兒。雖然有着經驗比較豐富的開發者會將數據從表示層分離開來，但這樣的良好設計一般並非很容易作到的，實現它須要精心地計劃和不斷的嘗試。MVC能夠從根本上強制性地將它們分開。儘管構造MVC應用程序須要一些額外的工做，可是它帶給咱們的好處是毋庸置疑的。
• 首先，多個 View 能共享一個 Model 。現在，同一個Web應用程序會提供多種用戶界面，例如用戶但願既可以經過瀏覽器來收發電子郵件，還但願經過手機來訪問電子郵箱，這就要求Web網站同時能提供Internet界面和WAP界面。在MVC設計模式中， Model 響應用戶請求並返回響應數據，View 負責格式化數據並把它們呈現給用戶，業務邏輯和表示層分離，同一個 Model 能夠被不一樣的 View 重用，因此大大提升了代碼的可重用性。
• 其次，Controller 是自包含（self-contained）指高獨立內聚的對象，與 Model 和 View 保持相對獨立，因此能夠方便的改變應用程序的數據層和業務規則。例如，把數據庫從Mysql移植到Oracle，或者把RDBMS數據源改變成LDAP數據源，只需改變 Model 便可。一旦正確地實現了控制器，無論數據來自數據庫仍是LDAP服務器，View 都會正確地顯示它們。因爲MVC模式的三個模塊相互獨立，改變其中一個不會影響其餘兩個，因此依據這種設計思想能構造良好的少互擾性的構件。
• 此外，Controller 提升了應用程序的靈活性和可配置性。Controller 能夠用來鏈接不一樣的 Model 和 View 去完成用戶的需求，也能夠構造應用程序提供強有力的手段。給定一些可重用的 Model 、 View 和Controller 能夠根據用戶的需求選擇適當的 Model 進行處理，而後選擇適當的的 View 將處理結果顯示給用戶。

MVC模式在概念上強調 Model, View, Controller 的分離，各個模塊也遵循着由 Controller 來處理消息，Model 掌管數據源，View 負責數據顯示的職責分離原則，所以在實現上，MVC 模式的 Framework 一般會將 MVC 三個部分分離實現：

• Model 負責數據訪問，較現代的 Framework 都會建議使用獨立的數據對象 (DTO, POCO, POJO 等) 來替代弱類型的集合對象。數據訪問的代碼會使用 Data Access 的代碼或是 ORM-based Framework，也能夠進一步使用 Repository Pattern 與 Unit of Works Pattern 來切割數據源的相依性。
• Controller 負責處理消息，較高級的 Framework 會有一個默認的實現來做爲 Controller 的基礎，例如 Spring 的 DispatcherServlet 或是 ASP.NET MVC 的 Controller 等，在職責分離原則的基礎上，每一個 Controller 負責的部分不一樣，所以會將各個 Controller 切割成不一樣的文件以利維護。
• View 負責顯示數據，這個部分多爲前端應用，而 Controller 會有一個機制將處理的結果 (多是 Model, 集合或是狀態等) 交給 View，而後由 View 來決定怎麼顯示。例如 Spring Framework 使用 JSP 或相應技術，ASP.NET MVC 則使用 Razor 處理數據的顯示。

也由於 MVC 模式強調職責分離，因此在發展 MVC 應用時會產生不少文件，在 IDE (集成開發環境) 不夠成熟時它會是個問題，但在現代主流 IDE 都能使用類別對象的信息來組織代碼編輯的狀況下，多文件早已不是問題，並且 MVC 模式會要求開發者進一步思考應用程序的架構 (Application Architecture)，而非用大雜燴的方式開發應用程序，對於應用程序的生命週期以及後續的可擴充與可維護性而言有至關正面的幫助。另外，MVC 職責分離也帶來了一個現代軟件工程要求的重要特性：可測試性 (Testability)，MVC-based 的應用程序在良好的職責分離的設計下，各個部分可獨立行使單元測試，有利於與企業內的自動化測試、持續集成 (Continuous Integration) 與持續發行 (Continuous Delivery) 流程集成，減小應用程序改版部署所需的時間。

MVC 模式的應用程序的目的就是但願打破以往應用程序使用的大雜燴程序撰寫方式，並間接誘使開發人員以更高的架構導向思惟來思考應用程序的設計，所以對於一個剛入門的初學者來講，架構導向的思考會有必定的門檻，須要較多的實現與練習才能具有相應的能力，大多數的初學者仍是較習慣於大雜燴式的程序撰寫，因此可能會對 MVC 模式抱持着排斥或厭惡的心態，然而 MVC (或是其餘的Design Patterns) 都是有助於應用程序長遠的發展，雖然大雜燴式的程序也能夠用來發展長生命週期的應用程序，可是相較於 MVC，大雜燴式的程序在可擴充性和可維護性 (尤爲是可測試性) 上會遠比 MVC 複雜不少，相反的，MVC 模式的應用程序是在初始開發時期必須先思考並使用軟件架構，使得開發時期會須要花較多心力，可是一旦應用程序完成後，可擴充性、可維護性和可測試性反而會由於 MVC 的特性而變得容易。

所以，MVC 模式在已有衆多優秀 Framework 的現代，早就己經沒有不適合小型應用的問題，小型的應用仍是能夠由 MVC Framework 的應用來獲取 MVC 的優勢，同時它也能做爲將來小型應用擴充到大型應用時的基礎與入門磚。若一開始就想要作大型應用，那麼 MVC 模式的職責分離以及要求開發的架構思考會更適合大型應用的開發。

MVC的實現

MFC

微軟所推出的MFC Document/View架構是早期對於MVC模式的實現，MFC將程序分紅CView以及CDocument兩大類別，其中的Document對應MVC中的 Model ，View 至關於MVC中的 View＋Controller，再加上CWinApp類別，合成三大項。可是基本上MFC是一個失敗的MVC模式做品。

因爲MFC之下的Document/View 定義過於模糊，未將Controller（MessageMap）部分取出，所以 Controller 能夠置入 View 或Document，但無論置入哪一方面，都會與View或Document綁死，沒有彈性。

Java

Java 平臺企業版 (J2EE)

和其餘的各類框架不同，J2EE爲模型對象（Model Objects）定義了一個規範。

視圖(View)

在J2EE應用程序中，視圖（View）可能由Java Server Page(JSP)擔任。生成 View 的代碼則多是一個servlet的一部分，特別是在客戶端服務端交互的時候。

控制器（Controller）J2EE應用中，Controller 多是一個servlet。除了可直接以J2EE來撰寫外，亦可用其餘框架來撰寫，常見的有Struts2、Spring Framework……等等。

模型（Model）

Model 則是由一個實體Bean來實現。

Java Swing

Swing是一個標準的MVC結構. ComponentUI表明 View, 負責描畫組件. 組件尤爲 Model 層, 好比JTextField的Document, JTable的TableModel, JTree的TreeModel等等. 而Control可能不是很明顯, 咱們或許能夠簡單的將其Event機制看做一個Swing團隊開發給開發者的 Controller。

做爲Java開發者, 若是想理解MVC的結構, 學習Swing的確是個不錯的選擇.

.NET

ASP.NET

在ASP.NET中，針對視圖（View）和控制器（Controller）的模式沒有被很好地定義。而模型（Model）則留給開發者去設計。

視圖（View）

ASPX和ASCX文件被用來處理 View 的職責。在這個設計中 View 其實是從 Controller 繼承而來。這個和Smalltalk的實施有所不一樣，在Smalltalk中不一樣的類都有指針互相指向對方.

控制器（Controllers）

Controller 的職責被分區成兩部分。事件（Event）的產生和傳輸是框架的一部分，更明確的說是Page和Control兩個類。而事件的處理則在分離的代碼中實現。

模型（Model）

ASP.NET 不嚴格須要一個 Model。開發者能夠自行選擇建立一個 Model 類，可是不少人選擇放棄這一步，直接把事件處理放在 Controller 裏處理任何計算、數據保存等等。但用 Model 來包含商業邏輯和數據訪問是可實現的。

ASP.NET MVC

ASP.NET MVC，在2013年10月17日穩定版本已到5.0版。此外，在ASP.NET MVC中，通常狀況下Model一般搭配LINQ to SQL類別（使用O/R Designer工具所製做而成的DBML檔）或ADO.NET實體數據模型（Entity Data Model，使用ADO.NET Entity Framework製做出的EDMX檔）來實現。

Windows Forms

在WinForms中，這個針對視圖（View）和控制器（Controller）的模式已經很好的定義。而模型（Model）則留給開發者去設計。

視圖（View）

由Form或者Control類繼承來的一個類處理 View 的職責。在WinForm這個例子中 View 和 Controller 被編譯在同一個類中，這個和ASP.NET不一樣。

控制器（Controller）

Controller 的職責被分區成三部分。事件（Event）的產生和傳輸是操做系統的一部分。在.Net框架中Form和Control類將不一樣的事件轉發給相應的事件處理器。而事件的處理則在分離的代碼中實現。

模型（Model）

就像ASP.NET同樣，WinForm不嚴格須要一個 Model。開發者能夠自行選擇建立一個 Model 類，可是不少人選擇放棄這一步，直接把事件處理放在 Controller 裏處理任何計算、數據保存等等。也就是說用Model來包含商業邏輯和數據訪問。

Perl

Catalyst和Jifty是經過Perl語言所開發出來的Web Framework，都採用Model-View-Controller 架構。Catalyst 自己只是作了 Controller，View 和 Model 讓開發者自由選用 CPAN 上的模塊開發，例如 Template 和 Template Declare 均可用來產生視圖。Jifty 將 MVC 徹底實作完成，View 的部分在早期版本使用 Mason 實作，較新版本使用 Template Declare。

Ruby on Rails

Ruby on Rails是經過Ruby語言所開發出來的 Web Framework，也是採用 Model-View-Controller 架構。Model 部分使用 Active Record 概念實作，加上 Migration 機制，使得其 Model 結構很是容易控制。

Python

Python 有許多的 MVC 架構。最經常使用的有 Django 和 TurboGears。

JavaScript

• Backbone.js
• Angular.js
• Ember.js
• JavaScriptMVC
• Model-View-Controller (MVC) with JavaScript

PHP

• CakePHP
• CodeIgniter
• prado
• symfony
• Yii Framework
• Zend Framework
• Phalcon
• Laravel

ActionScript 3

• PureMVC Standard for ActionScript 3

MVC的不足之處

（1） 增長了系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增長結構的複雜性，並可能產生過多的更新操做，下降運行效率。 （2） 視圖與控制器間的過於緊密的鏈接。視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是頗有限的，反之亦然，這樣就妨礙了他們的獨立重用。 （3） 視圖對模型數據的低效率訪問。依據模型操做接口的不一樣，視圖可能須要屢次調用才能得到足夠的顯示數據。對未變化數據的沒必要要的頻繁訪問，也將損害操做性能。 （4） 目前，通常高級的界面工具或構造器不支持MVC模式。改造這些工具以適應MVC須要和創建分離的部件的代價是很高的，從而形成使用MVC的困難。