MVC设计模式

MVC架构是随着SmalltalkLanguage语言的发展提出的，它是一个著名的用户界面设计架构。MVC英文即Model-View-Controller（模型－视图－控制器），即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三部分——模型、视图和控制器。所谓 MVC 设计模式，是指一种划分系统功能的方法，是为那些需要为同样的数据提供多个视图的应用程序而设计的，它实现了数据层与表示层的分离，特别适用于开发与用户图形界面有关的应用程序。

MVC设计模式的基本结构定义为：

（1）控制器，用来处理用户命令以及程序事件；

（2）模型，用来维护数据并提供数据访问方法；

（3）视图，负责数据的显示。

MVC设计模式的用处非常广泛。在开发一个应用系统的过程中，随着客户新需求的不断增多，进行软件系统功能的修改和扩充是迫在眉睫的，但是因为程序的高耦合，改动会变得非常困难，这样就会导致项目成本和风险的增加。而且，一般来说，维护人员与开发人员不是同一个人，即使说明文档很详细，也很难真正理清程序里错综复杂的联系。所以使用MVC 设计模式设计整体框架，在设计阶段就杜绝此类问题，是一个非常好的软件设计方法。当一个应用既包含数据访问代码，又包含业务逻辑代码以及描述代码时，就会产生一些问题。这样的应用是很难维护的，因为无论何时产生一个新变化，所有组件之间的相互依赖都会引起强烈的波动效应。由于一个类过多的依赖于其他的类而导致的高耦合使得类变得难于重用或者根本不可能重用。添加新的数据时视图通常需要重新执行业务逻辑代码，这就需要在多个位置对该业务逻辑代码进行维护，数据访问代码也会产生同样的问题。MVC 设计模式通过减弱数据访问、业务逻辑以及数据描述与用户的交互而解决了这些问题。本质上来说，MVC 设计模式将应用分为以下三个部分：模型、控制器、视图。

（1）模型包含了应用问题的核心数据、逻辑关系和计算功能，它封装了所需的数据，提供了完成问题处理的操作过程。控制器依据I/O的需要调用这些操作过程。模型还为视图获取显示数据而提供了访问其数据的操作。这种变化—传播机制体现在各个相互依赖部件之间的注册关系上。模型数据和状态的变化会激发这种变化-传播机制，它是模型、视图和控制器之间联系的纽带。

（2）视图通过显示的形式，把信息转达给用户。不同视图通过不同的显示，来表达模型的数据和状态信息。每个视图有一个更新操作，它可被变化-传播机制所激活。当调用更新操作时，视图获得来自模型的数据值，并用它们来更新显示。在初始化时，通过与变化-传播机制的注册关系建立起所有视图与模型间的关联。视图与控制器之间保持着一对一的关系，每个视图创建一个相应的控制器。视图提供给控制器处理显示的操作。因此，控制器可以获得主动激发界面更新的能力。

（3）控制器通过时间触发的方式，接受用户的输入。控制器如何获得事件依赖于界面的运行平台。控制器通过事件处理过程对输入事件进行处理，并为每个输入事件提供了相应的操作服务，把事件转化成对模型或相关视图的激发操作。

MVC中的模型、视图和控制类

如果控制器的行为依赖于模型的状态，则控制器应该在变化-传播机制中进行注册，并提供一个更新操作。这样，可以由模型的变化来改变控制器的行为，如禁止某些操作。

（1）分析应用问题，对系统进行分离

分析应用问题，分离出系统的内核功能、对功能的控制输入、系统的输出行为三大部分。设计模型部件使其封装内核数据和计算功能，提供访问显示数据的操作，提供控制内部行为的操作以及其他必要的操作接口。以上形成模型类的数据构成和计算关系。这部分的构成与具体的应用问题紧密相关。

（2）设计和实现每个视图

设计每个视图的显示形式，它从模型中获取数据，将它们显示在屏幕上。MVC设计模式，是指一种划分系统功能的方法，是为那些需要为同样的数据提供多个视图的应用程序而设计的，它实现了数据层与表示层的分离，特别适用于开发与用户图形界面有关的应用程序。

（3）设计和实现每个控制器

对于每个视图，指定对用户操作的响应时间和行为。在模型状态的影响下，控制器使用特定的方法接受和解释这些事件。控制器的初始化建立起与模型和视图的联系，并且启动事件处理机制。事件处理机制的具体实现方法依赖于界面的工作平台。

（4）使用可安装和卸载的控制器

控制器的可安装性和可卸载性，带来了更高的自由度，并且帮助形成高度灵活性的应用。控制器与视图的分离，支持了视图与不同控制器结合的灵活性，以实现不同的操作模式，例如对普通用户、专业用户、或不使用控制器建立的只读视图。这种分离还为在应用中集成新的I/O设备提供了途径。

MVC的实现过程

把模型、视图、控制器实行分离，使设计和使用有了很大灵活性。但是，在现实中，视图和控制器的功能通常是紧密地联系在一起的。控制视图工作的输入事件通常都是与视图的构成相关的。在现实界面设计环境中，界面操作事件及其处理都是与界面形式设计紧密关联的。在这种情况下，把视图和控制器分离开，就给分析和设计带了了不方便，并且运行的效率低。

因此，可以把视图和控制器结合起来加以设计和实现。在上面的实现说明中，只要把视图和控制器的类合并生成新的视图类即可。这样，仍然保持着与模型的分离，因此相同的模型仍然可以使用多个视图。这些视图本身已经具备了事件处理能力，仍然可以通过模型对其功能进行控制。

MVC的优点表现在以下几个方面：

（1）可以为一个模型在运行时同时建立和使用多个视图。变化-传播机制可以确保所有相关的视图及时得到模型数据变化，从而使所有关联的视图和控制器做到行为同步。

（2）视图与控制器的可接插性，允许更换视图和控制器对象，而且可以根据需求动态的打开或关闭、甚至在运行期间进行对象替换。

（3）模型的可移植性。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。需要做的只是在新平台上对视图和控制器进行新的修改。

（4）潜在的框架结构。可以基于此模型建立应用程序框架，不仅仅是用在设计界面的设计中。

MVC的不足表现在以下几个方面：

（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

（4）目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

Struts的目的是为了帮助我们减少在运用MVC设计模型来开发Web应用的时间。早期Smalltalk程序语言便采用了MVC(Model-View -Controller)模式(Patterns)以增加程序代码弹性，MVC模式将程序代码整理切割为三部分，Model 部分是业务与应用领域（Business domain)相关逻辑、管理状态之对象，Controller 部分接收来自View 所输入的资料并与Model 部分互动，是业务流程控制（Flow Control）之处，View 部分则负责展现资料、接收使用者输入资料。基于struts构架的web应用程序是一个传统 MVC设计模式的一种变化类型。

ThinkPHP 也是基于MVC设计模式的。ThinkPHP中的MVC分层大致体现在：

模型（M）：模型的定义由Model类来完成。

控制器（C）：应用控制器（核心控制器App类）和Action控制器都承担了控制器的角色，Action控制器完成业务过程控制，而应用控制器负责调度控制。

视图（V）：由View类和模板文件组成，模板做到了100％分离，可以独立预览和制作。但实际上，ThinkPHP并不依赖M或者V ，甚至也不依赖C，总而言之，ThinkPHP的MVC模式只是提供了一种敏捷开发的手段，而不是拘泥于MVC本身。

类似的模式结构还有PAC（Presentation-Abstraction-Control）、Forward-Receiver、Publisher-Subscriber、各类可视化用户界面控件等。

其中，“表示-抽象-控制”结构模式（PAC）也是从数据模型及其可是化关系的处理上提出的。其中，表示与视图对应，抽象与模型对应，控制与控制对应。从逻辑本质上，两者没有太大区别。但是，MVC和PAC还是存在着不同的地方。

（1）MVC的控制更侧重于在视图上的用户的I/O处理，而PAC的控制主要指从抽象到表示的传递和协调作用。

（2）此外，PAC把系统分割为协作但松散耦合的智能体，而MVC是专门处理交互界面的，各个部件之间的关联更密切一些。

（3）另外，从体系结构上看，PAC是属于系统级别的，因为它解决的问题更倾向于系统及部件之间的协作和关联关系。