MVC--全称是：Model-View-Controller，即模型-视图-控制器 模式是一个相当老的设计模式，它的一些变体至少在Smarttalk的早期就出现了。它是一种高级别的模式，关住的是应用程序的全局架构，并根据各种对象在程序中发挥的作用对其进行分类。它也是个复合的模式，因为它是由几个更加基本的模式组成的。
面向对象的程序在设计上采用MVC模式会带来几个方面的好处。这种程序中的很多对象可能更具重用性，它们的借口也可能定义的更加良好。程序从总体上更加适应需求的改变，换句话说，它们比不基于MVC的程序更加容易扩展。而且，Cocoa中的很多技术和架构——比如绑定技术、文档架构。和脚本技术等于MVC，而且要求定制对象充当MVC定义的某种角色。
一、MVC设计思想
MVC全称英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能。
二、MVC对象的作用和关系
MVC设计模式考虑三种对象：模型对象，视图对象，和控制对象。模式定义了这个这三种对象在应用程序中充当的角色，以及他们的通讯路径。在设计应用程序时，一个主要的步骤就是进行这三种对象的选择或者说这三种对象创建定制类。三种对象中的每一种都和其他两种按抽象的边界区分，并和其他两种对象进行跨边界的通讯。
1），模型对象负责包装数据和基本行为
模型对象代表特别的知识和专业技能，他们负责保有应用程序的数据额和定义操作数据的逻辑。一个定义良好的MVC应用程序将所有重要的数据封装在模型对象中。任何代表应用程序留存状态的数据（无论该状态存储在文件中，还是存储在数据库中），一旦载入应用程序，就应该主流在模型对象中。因为它们代表与特定问题域有关知识和专业技能，所以有可能被重用。
2），视图对象负责向用户表示信息
视图对象知道如何显示应用程序的模型数据，而且可能允许用户对其进行编辑。视图对象不应该负责存储它所显示的数据（这当然不是说视图永远不存储它所显示的数据。由于性能上的原因，视图可能对数据进行缓存，或使用类似的技巧）。一个视图对象可能负责显示墨香对象那个的一部分或全部，甚至是很多不同的模型对象。视图对象可能有很多变化。
3），控制器对象链接模型和视图
控制器对象是应用程序的视图对象和模型对象之间的协调者。通常情况下，他们负责保证视图可以访问其显示的模型，并充当交流的管道，使视图可以了解模型发生的变化。控制器对象也可以为应用程序执行配置和协调的任务，管理其他队象的生命周期。
4），组合角色
可以将多个MVC角色组合起来，使一个对象冲淡多个角色，比如同时充当控制器和视图对象的角色-在这个情况下，该对象被称为视图-控制器。同样的，也可以有模型-控制器对象。队友某些应用程序，像这样的角色组合是可接收的设计。
三、MVC的优点
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。
首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。
再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。
四、MVC的不足
MVC的不足体现在以下几个方面：
（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
总结一下：
MVC（模型-视图-控制器模式），是一种高级别的模式，关住的是应用程序的全局架构，并根据各种对象在程序中发挥的作用对其进行分类。
MVC是一个复合的设计模式，是由合成、策略和观察者模式组成。
