1 前言
用户界面，特别是图形用户界面，承担着向用户显示问题模型和与用户进行操作和I/O交互的作用。用户希望保持交互操作界面的相对稳定，但更希望根据需要改变和调整显示的内容和形式。例如，要求支持不同的界面标准或得到不同的显示效果，适应不同的操作需求。这就要求界面结构能够在不改变软件的功能和模型情况下，支持用户对界面构成的调整。
要做到这一点，从界面构成的角度看，困难在于：在满足对界面要求的同时，如何使软件的计算模型独立于界面的构成。模型-视图-控制（MVC：Model-View-Controller）就是这样的一种交互界面的结构组织模型。
2 MVC（Model-View-Control）
MVC由Trygve Reenskaug提出，首先被应用在SmallTalk-80环境中，使许多交互和界面系统的构成基础，Microsoft的MFC基础类也遵循了MVC的思想。
对于界面设计可变性的需求，MVC把交互系统的组成分解成模型、视图、控制三种部件。
模型部件是软件所处理问题逻辑在独立于外在显示内容和形式情况下的内在抽象，封装了问题的核心数据、逻辑和功能的计算关系，他独立于具体的界面表达和I/O操作。
视图部件把表示模型数据及逻辑关系和状态的信息及特定形式展示给用户。它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式或视图。
控制部件是处理用户与软件的交互操作的，其职责是控制提供模型中任何变化的传播，确保用户界面于模型间的对应联系；它接受用户的输入，将输入反馈给模型，进而实现对模型的计算控制，是使模型和视图协调工作的部件。通常一个视图具有一个控制器。
模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。
2.1 MVC中的模型、视图和控制类
MVC中的模型、视图和控制类如图1所示。
（1） 模型包含了应用问题的核心数据、逻辑关系和计算功能，它封装了所需的数据，提供了完成问题处理的操作过程。控制器依据I/O的需要调用这些操作过程。模型还为视图获取显示数据而提供了访问其数据的操作。
这种变化-传播机制体现在各个相互依赖部件之间的注册关系上。模型数据和状态的变化会激发这种变化-传播机制，它是模型、视图和控制器之间联系的纽带。
（2） 视图通过显示的形式，把信息转达给用户。不同视图通过不同的显示，来表达模型的数据和状态信息。每个视图有一个更新操作，它可被变化-传播机制所激活。当调用更新操作时，视图获得来自模型的数据值，并用它们来更新显示。
在初始化时，通过与变化-传播机制的注册关系建立起所有视图与模型间的关联。视图与控制器之间保持着一对一的关系，每个视图创建一个相应的控制器。视图提供给控制器处理显示的操作。因此，控制器可以获得主动激发界面更新的能力。
（3） 控制器通过时间触发的方式，接受用户的输入。控制器如何获得事件依赖于界面的运行平台。控制器通过事件处理过程对输入事件进行处理，并为每个输入事件提供了相应的操作服务，把事件转化成对模型或相关视图的激发操作。
如果控制器的行为依赖于模型的状态，则控制器应该在变化-传播机制中进行注册，并提供一个更新操作。这样，可以由模型的变化来改变控制器的行为，如禁止某些操作。
3 MVC的实现
实现基于MVC的应用需要完成以下工作，如图2所示：
3.1 分析应用问题，对系统进行分离
分析应用问题，分离出系统的内核功能、对功能的控制输入、系统的输出行为三大部分。设计模型部件使其封装内核数据和计算功能，提供访问显示数据的操作，提供控制内部行为的操作以及其他必要的操作接口。以上形成模型类的数据构成和计算关系。这部分的构成与具体的应用问题紧密相关。
3.2 设计和实现每个视图
设计每个视图的显示形式，它从模型中获取数据，将它们显示在屏幕上。
3.3 设计和实现每个控制器
对于每个视图，指定对用户操作的响应时间和行为。在模型状态的影响下，控制器使用特定的方法接受和解释这些事件。控制器的初始化建立起与模型和视图的联系，并且启动事件处理机制。事件处理机制的具体实现方法依赖于界面的工作平台。
3.4 使用可安装和卸载的控制器
控制器的可安装性和可卸载性，带来了更高的自由度，并且帮助形成高度灵活性的应用。控制器与视图的分离，支持了视图与不同控制器结合的灵活性，以实现不同的操作模式，例如对普通用户、专业用户、或不使用控制器建立的只读视图。这种分离还为在应用中集成新的I/O设备提供了途径。
4 MVC的变化
把模型、视图、控制器实行分离，使设计和使用有了很大灵活性。但是，在现实中，视图和控制器的功能通常是紧密地联系在一起的。控制视图工作的输入事件通常都是与视图的构成相关的。在现实界面设计环境中，界面操作事件及其处理都是与界面形式设计紧密关联的。在这种情况下，把视图和控制器分离开，就给分析和设计带了了不方便，并且运行的效率低。
因此，可以把视图和控制器结合起来加以设计和实现。在上面的实现说明中，只要把视图和控制器的类合并生成新的视图类即可。这样，仍然保持着与模型的分离，因此相同的模型仍然可以使用多个视图。这些视图本身已经具备了事件处理能力，仍然可以通过模型对其功能进行控制。
5 MVC的优点及不足之处
5.1 MVC的优点
MVC的优点表现在以下几个方面：
（1） 可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。
（2） 视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。
（3） 模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。
（4） 潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。
5.2 MVC的不足之处
MVC的不足表现在以下几个方面：
（1） 增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
（2） 视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
（4） 目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
6 其他类似的模式
类似的结构模式还有PAC（Presentation-Abstraction-Control）、Forward-Receiver、Publisher-Subscriber、各类可视化用户界面控件等。
其中，"表示-抽象-控制"结构模式（PAC）也是从数据模型及其可是化关系的处理上提出的。其中，表示与视图对应，抽象与模型对应，控制与控制对应。从逻辑本质上，两者没有太大区别。但是，MVC和PAC还是存在着不同的地方。
（1） MVC的控制更侧重于在视图上的用户的I/O处理，而PAC的控制主要指从抽象到表示的传递和协调作用。
（2） 此外，PAC把系统分割为协作但松散耦合的智能体，而MVC是专门处理交互界面的，各个部件之间的关联更密切一些。
（3） 另外，从体系结构上看，PAC是属于系统级别的，因为它解决的问题更倾向于系统及部件之间的协作和关联关系。
7 小结
与软件所处理问题的内在模型相比较，用户界面是需要经常发生变化的，采用MVC设计模式可以在满足对界面要求的同时，使软件的计算模型独立于界面的构成。本文首先介绍了MVC的三个组成构件（模型构件、视图构件和控制构件），以及实现基于MVC的应用需要完成的工作；接着，对MVC的优点及不足之处进行了分析；最后，介绍了几种其他类似的结构模式，并对MVC和PAC进行了比较。
8 参考书目
1 万建成、卢雷 编著，《软件体系结构的原理、组成与应用》，科学出版社，2002
2 齐治昌、谭庆平、宁洪 编著 《软件工程》 北京：高等教育出版社 1997
3 （美）Roger S.Pressman 著，黄柏素、梅宏译 《软件工程──实践者的研究方法（第四版）》北京：机械工业出版社 1999