MVC模式(Model–view–controller)是軟件工程中的一種軟件架構模式,把軟件系統分爲三個基本部分:模型(Model)、視圖(View)和控制器(Controller)。php
MVC模式最先由TrygveReenskaug在1978年提出,是施樂帕羅奧多研究中心(Xerox PARC)在20世紀80年代爲程序語言Smalltalk發明的一種軟件架構。的目的是實現一種動態的程序設計,使後續對程序的修改和擴展簡化,而且使程序某一部分的重複利用成爲可能。除此以外,此模式經過對複雜度的簡化,使程序結構更加直觀。軟件系統經過對自身基本部分分離的同時也賦予了各個基本部分應有的功能。專業人員能夠經過自身的專長分組:前端
將應用程序劃分爲三種組件,模型 - 視圖 - 控制器(MVC)設計定義它們之間的相互做用。模型用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。「 Model 」有對數據直接訪問的權力,例如對數據庫的訪問。「Model」不依賴「View」和「Controller」,也就是說, Model 不關心它會被如何顯示或是如何被操做。可是 Model 中數據的變化通常會經過一種刷新機制被公佈。爲了實現這種機制,那些用於監視此 Model 的 View 必須事先在此 Model 上註冊,從而,View 能夠了解在數據 Model 上發生的改變。視圖(View)可以實現數據有目的的顯示(理論上,這不是必需的)。在 View 中通常沒有程序上的邏輯。爲了實現 View 上的刷新功能,View 須要訪問它監視的數據模型(Model),所以應該事先在被它監視的數據那裏註冊。node
MVC模式在概念上強調 Model, View, Controller 的分離,各個模塊也遵循着由 Controller 來處理消息,Model 掌管數據源,View 負責數據顯示的職責分離原則,所以在實現上,MVC 模式的 Framework 一般會將 MVC 三個部分分離實現:laravel
也由於 MVC 模式強調職責分離,因此在發展 MVC 應用時會產生不少文件,在 IDE (集成開發環境) 不夠成熟時它會是個問題,但在現代主流 IDE 都能使用類別對象的信息來組織代碼編輯的狀況下,多文件早已不是問題,並且 MVC 模式會要求開發者進一步思考應用程序的架構 (Application Architecture),而非用大雜燴的方式開發應用程序,對於應用程序的生命週期以及後續的可擴充與可維護性而言有至關正面的幫助。另外,MVC 職責分離也帶來了一個現代軟件工程要求的重要特性:可測試性 (Testability),MVC-based 的應用程序在良好的職責分離的設計下,各個部分可獨立行使單元測試,有利於與企業內的自動化測試、持續集成 (Continuous Integration) 與持續發行 (Continuous Delivery) 流程集成,減小應用程序改版部署所需的時間。程序員
MVC 模式的應用程序的目的就是但願打破以往應用程序使用的大雜燴程序撰寫方式,並間接誘使開發人員以更高的架構導向思惟來思考應用程序的設計,所以對於一個剛入門的初學者來講,架構導向的思考會有必定的門檻,須要較多的實現與練習才能具有相應的能力,大多數的初學者仍是較習慣於大雜燴式的程序撰寫,因此可能會對 MVC 模式抱持着排斥或厭惡的心態,然而 MVC (或是其餘的Design Patterns) 都是有助於應用程序長遠的發展,雖然大雜燴式的程序也能夠用來發展長生命週期的應用程序,可是相較於 MVC,大雜燴式的程序在可擴充性和可維護性 (尤爲是可測試性) 上會遠比 MVC 複雜不少,相反的,MVC 模式的應用程序是在初始開發時期必須先思考並使用軟件架構,使得開發時期會須要花較多心力,可是一旦應用程序完成後,可擴充性、可維護性和可測試性反而會由於 MVC 的特性而變得容易。angularjs
所以,MVC 模式在已有衆多優秀 Framework 的現代,早就己經沒有不適合小型應用的問題,小型的應用仍是能夠由 MVC Framework 的應用來獲取 MVC 的優勢,同時它也能做爲將來小型應用擴充到大型應用時的基礎與入門磚。若一開始就想要作大型應用,那麼 MVC 模式的職責分離以及要求開發的架構思考會更適合大型應用的開發。算法
MVC的實現sql
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 平臺企業版 (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的確是個不錯的選擇.
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
ActionScript 3
MVC的不足之處
(1) 增長了系統結構和實現的複雜性。對於簡單的界面,嚴格遵循MVC,使模型、視圖與控制器分離,會增長結構的複雜性,並可能產生過多的更新操做,下降運行效率。 (2) 視圖與控制器間的過於緊密的鏈接。視圖與控制器是相互分離,但確實聯繫緊密的部件,視圖沒有控制器的存在,其應用是頗有限的,反之亦然,這樣就妨礙了他們的獨立重用。 (3) 視圖對模型數據的低效率訪問。依據模型操做接口的不一樣,視圖可能須要屢次調用才能得到足夠的顯示數據。對未變化數據的沒必要要的頻繁訪問,也將損害操做性能。 (4) 目前,通常高級的界面工具或構造器不支持MVC模式。改造這些工具以適應MVC須要和創建分離的部件的代價是很高的,從而形成使用MVC的困難。