简介：

MVC是三个单词的缩写,分别为： 模型(Model),视图 (View)和控制Controller)。MVC模式最早由Trygve Reenskaug 在1974年提出，是施乐帕罗奥多研究中心 （Xerox PARC）在20世纪80年代为程序语言Smalltalk 发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Sun公司J2EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。

MVC模式的目的是实现一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外此模式通过对复杂度的简化使程序结构更加直观。软件系统通过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。

 

C/S 下的 MVC ：

MVC原本是为C/S系 统解决模型与视图的分离，使模型能够更好的复用。与软件所处理问题的内在模型相比较，用户界面是需要经常发生变化的，用户希望保持交互操作界面的相对稳 定，但更希望根据需要改变和调整显示的内容和形式。例如，要求支持不同的界面标准或得到不同的显示效果，适应不同的操作需求。这就要求界面结构能够在不改 变软件的功能和模型情况下，支持用户对界面构成的调整。

图1-1显 示了一个模型和三个视图（为了简单起见我们省略了控制器）。模型包括一些数据值，视图通过电子表格，柱状图，饼图这些不同的方式显示这些数据。每种视图可 能在同一时间显示给不同的用户，应用必须保证在其下面的数据或模型改变时视图的更新。为改变模型，用户提交一个请求给控制器，由控制器来配合改变模型。数 据视图必须跟着改变，以反映最近的模型改变状态。

图1-1

对于界面设计可变性的需求，MVC把交互系统的组成分解成模型、视图、控制三种部件。

模型部件是软件所处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象，封装了问题的核心数据、逻辑和功能的计算关系，他独立于具体的界面表达和I/O操作。

视图部件把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。

控制部件是处理用户与软件的交互操作的，其职责是控制提供模型中任何变化的传播，确保用户界面于模型间的对应联系；它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制，是使模型和视图协调工作的部件。通常一个视图具有一个控制器。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应 反映 到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的通知/订阅者机制。

这种通知/订阅者机制体现在各个相互依赖部件之间的注册关系上。模型数据和状态的变化会激发这种通知/订阅者机制，它是模型、视图和控制器之间联系 的纽带。在视图初始化时，通过与通知/订阅者机制的注册关系建立起所有视图与模型间的关联。视图与控制器之间保持着一对一的关系，每个视图创建一个相应的 控制器。视图提供给控制器处理显示的操作。因此，控制器可以获得主动激发界面更新的能力。

图1-2和图1-3都表示了M-V-C之间的关系。

图1-2

图1-3

J2EE Web 下的MVC

在web早期的开发中，通常采用的都是model1。Model1设计模式中，主要分为两层，视图层和模型层。那么，项目中的业务流程该如何处理 呢？实际上，model1模式中jsp就充当了这个角色，也就是说一切的业务逻辑都是由jsp来处理的，通常是通过jsp直接调用模型来处理相关的业 务，model1是以jsp为 中心的。强大的功能伴随着巨大的责任，很多团队发现，如果他们一不小心，他们的项目就会绞缠与如麻的页面变的容易崩溃。页面间经常通过“拷贝粘贴”的方式 复用一些业务流程代码，并且会创建很多工具页面，但它们很难被组织在一起，造成非常丑陋的“资源”树。有些东西会出错。

很多开发人员很快意识到，JS和servlet可以一起使用来部署web应用。Servlet可以应付控制流，而JSP则可专注于讨厌的编写 HTML的任务。在这种情况下，结合使用JSP和servlet开始被称为Model2。很多人很快指出JSP Model2类似于经典的Model-View-Controller架构。

在很多场合，现在交互使用Model2和MVC 这两个词已经很平常了，虽然还有一些争论，即一个应用是否是MVC，以及是否支持经典的观察者通知模式。没有观察者通知的web下的Model-View-Controlle有时被称为MVC2  或Web MVC。

典型的Model-View-Controller 范式，经常被表示为：一个互相连接的三角形。在web  应用中维护范式中的“通知改变”部分是非常困难的。这些东西在所有资源都在一台服务器上，而且客户端保持一个开放连接的情况下工作得非常好。如果资源分布 在不同的服务器上，并且客户端不能维护一个开放的连接情况下，工作的并不理想。许多分布式系统架构，包括web 应用，在视图进行状态查询的概念时退缩了。绝大多数情况下，远程应用是按层模式[POSA]设计的。基本上，层模式下，层内的对象可以和同一层或者相邻层 的对象进行通信。在一个复杂应用中，这可以在添加组件时，防止依赖关系呈指数增长。在设计远程应用时，分层是一个核心模式。从 MVC  上下文中，引入层模式将状态改变和状态查询的职责加于控制器之上，并伴随着改变通知。

图1-4

如图1-4，分层的web 应用使用一种比传统MVC 模式更加“扁平”的模式。控制器被夹在表现层(View)和应用逻辑(Model)之间。每个组件的主要职责并没有改变。流程有轻微改变，即查询状态和改 变通知都必须通过控制器。另一个改变是，当视图，或者表现层需要渲染动态页面时，它使用从控制器传递的数据而不是直接来自于模型层。这种改变去除了 View和Model的耦合，允许控制器选择数据和显示这些数据的视图。