MVC

title: 组件的互动.
content: 将应用程序划分为三种组件,模型 - 视图 - 控制器(MVC)设计定义它们之间的相互作用。
title: 优点.
content: 在最初的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 将处理结果显示给用户。
title: 评价、误解及适用范围.
content: MVC模式在概念上强调 Model, View, Controller 的分离,各个模组也遵循着由 Controller 来处理讯息,Model 掌管资料来源,View 负责资料显示的职责分离原则,因此在实作上,MVC 模式的 Framework 通常会将 MVC 三个部分分离实作:  也因为 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 模式的职责分离以及要求开发的架构思考会更适合大型应用的开发。
title: 实际范例.
content: 这里有一个通过 JavaScript 所实现的基于 MVC 模型,需要注意的是:MVC 不是一种技术,而是一种理念。 /** 模拟 Model, View, Controller */ var M = {}, V = {}, C = {};  /** Model 负责存放资料 */ M.data = "hello world";  /** View 负责将资料输出到萤幕上 */  /** Controller 作为一个 M 和 V 的桥梁 */  /** 在网页读取的时候呼叫 Controller */ window.onload = C.handleOnload;在这个简短的程序码中就具有一个完整的 MVC 模式。
title: 实现.
title: MFC.
content: 微软所推出的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绑死,没有弹性。
title: Java.
title: Java 平台企业版 (J2EE).
content: 和其他的各种框架不一样,J2EE为模型对象(Model Objects)定义了一个规范。
title: Java Swing.
content: Swing是一个标准的MVC结构. ComponentUI代表 View, 负责描画组件. 组件尤其 Model 层, 比如JTextField的Document, JTable的TableModel, JTree的TreeModel等等. 而Control可能不是很明显, 我们或许可以简单的将其Event机制看作一个Swing团队开发给开发者的 Controller。  作为Java开发者, 如果想理解MVC的结构, 学习Swing的确是个不错的选择.
title: .NET.
title: ASP.NET.
content: 在ASP.NET中,针对视图(View)和控制器(Controller)的模式没有被很好地定义。而模型(Model)则留给开发者去设计。
title: ASP.NET MVC.
content: 此外,在ASP.NET MVC中,一般情况下Model通常搭配LINQ to SQL类别(使用O/R Designer工具所制作而成的DBML档)或ADO.NET实体资料模型(Entity Data Model,使用ADO.NET Entity Framework制作出的EDMX档)来实作。
title: Windows Forms.
content: 在WinForms中,这个针对视图(View)和控制器(Controller)的模式已经很好的定义。而模型(Model)则留给开发者去设计。
title: Perl.
content: Catalyst和Jifty是透过Perl语言所开发出来的Web Framework,都采用Model-View-Controller 架构。Catalyst 本身只是做了 Controller,View 和 Model 让开发者自由选用 CPAN 上的模组开发,例如 Template 和 Template Declare 都可用来产生视图。Jifty 将 MVC 完全实做完成,View 的部分在早期版本使用 Mason 实做,较新版本使用 Template Declare。
title: Ruby on Rails.
content: Ruby on Rails是透过Ruby语言所开发出来的 Web Framework,也是采用 Model-View-Controller 架构。Model 部分使用 Active Record 概念实做,加上 Migration 机制,使得其 Model 结构非常容易控制。
title: Python.
content: Python 有许多的 MVC 架构。最常用的有 Django 和 TurboGears。

Summary: MVC模式(Model–view–controller)是软件工程中的一种软件架构模式,把软件系统分为三个基本部分:模型(Model)、视图(View)和控制器(Controller)。

Model View Controller: Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in Smalltalk durch Trygve Reenskaug beschrieben (Seeheim-Modell), der damals an Smalltalk im Xerox PARC arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.