模型-视图-控制器MVC（Model-View-Controller）设计模式是随着Smalltalk语言的发展而提出的，它是一个著名的用户界面设计架构。其应用架构把应用系统划分为3个相互协调的部分：模型(Model)，包含应用程序的核心功能，封装系统的状态；视图(View)，是模型的动态表示，并提供用户交互界面；控制器(Controller)，接受来自视图的请求，修改模型的状态，同时根据模型状态的变化更新视图。

图1：一个基本的层次划分

MVC是分析和设计Web应用程序最常用的模式，它同时也是很多Web应用程序开发框架所依据的架构模式，它为软件的分层及实现提供了一种稳定而成熟的结构方案和开发方法。随着互联网应用的不断发展，很多传统的应用程序被转移到网络平台上运行，Web应用程序也正被用来实现越来越多、越来越复杂的应用逻辑，这些都使其本身也变得越来越复杂而难以控制。

万能JSP方法

早期的开发人员使用一种较为直接的方法来开发B/S结构的Web应用程序，这种方法明显地带有C/S程序开发的特点。他们不仅在视图中实现软件界面逻辑，还在其中实现很多应用逻辑。

以JSP程序开发为例，程序员不仅使用JSP页面进行数据显示和响应用户操作，还在其中处理诸如数据库连接、数据操作、权限控制、程序流转等应用逻辑。

这种开发方式虽然较为直观，但是不同类型的代码混杂在一个页面中，显得零乱而不易维护。这种Web应用程序开发方法没有形成明显的开发框架，常被称为Model1方法，也被戏称为“万能JSP方法”。

MVC模式——Web应用设计的主流

为了能有效的控制开发，MVC模式诞生了，并且成为分析和设计Web应用程序最常用的模式。

通常对于一个应用领域的问题，我们会进行如图1所示的基本层次划分。对于熟悉MVC模式的软件设计师，他们通常会利用一种有效的设计模式来实现此类层次结构，即分别地设计问题域中面向应用的部件和面向数据的部件，并用一个问题语境下的控制器部件来处理它们之间的交互。

这种经典结构给问题的解决提供了一个清晰的层次模型，增加了解决方案的扩展性和维护性，而且在实现上也有很多经验甚至代码可以借鉴，从而也增加了软件的成熟性，并减少了开发的难度。

因此MVC模式成为Web应用程序设计的主流方式，以此模式为基础，出现了很多各具特色的开发框架，其中代表性的有WAF、Struts、WebWork等。这种基于MVC模式的Web应用程序开发方法被统称为Model2方法。

递归MVC应运而生

虽然MVC模式对于较简单的Web应用程序来说，是一个非常行之有效的分析模式和设计方法，但是相对于Web应用程序复杂性的快速增长来说，传统的MVC结构已显得过于单薄和简单，其对应用逻辑容量和扩展性的改善也显得相当有限。问题越来越多地表现在：

1.随着Web应用程序中实现的应用逻辑的增加，依据MVC模式分离出来的Model层、Controller层和View层都已变得更加复杂而难以控制。直接构造这些层次的风险也急剧增加。

2.Controller层中的情况更加糟糕，应用系统的数据逻辑、应用逻辑和显示逻辑混杂在一起管理和实现，模糊了系统的层次结构，这常会使系统变得过于僵硬，由于各层次间的交互方式和过程显得过于随意，程序也比较难以维护。

3.数据的传输路线和控制过程不够清晰，常使各个部件间产生不合理的跨层依赖，程序的整体结构受到很大影响。

4.界面的实现和流转过于依赖控制器，大量功能单一的页面文件造成频繁的流转控制和繁琐的状态控制，这给控制器造成很大的负担，也会严重损害系统的性能和扩展性。

为了解决上述问题，一个在传统MVC结构的基础上递归地应用MVC模式的分析模式被提出。利用MVC模式解决应用程序结构问题的基本思路，去解决MVC结构本身的构造问题。

这种应用方式虽然增加了应用程序结构复杂性，却可以使其基础构造单元的复杂度得以快速地降低，使系统的层次结构显得更加清晰，系统扩展性得到增强，从而为MVC应用程序以更高的效率实现更加复杂的功能打下良好的基础。

从三角形结构到双键结构

MVC在应用过程中，随着应用程序运行环境的变化和采用的编程语言的变化，其应用形态也经历了多次调整和改变。但是利用MVC模式进行软件分析、设计和构造的基本思想并没有改变。

早期的MVC结构的应用形态常呈一种三角形的结构，如图2所示。在这种形态结构中，MVC的各个部分：Model、View、Controller之间都存在着关联或依赖关系。

图2：MVC的三角形结构

这是由于当时的应用程序普遍采用Client/Server结构(以下简称C/S结构)进行开发，这种结构中软件系统的View与Model通常以相同的编程语言进行开发，同时它们之间有方便的、基于连接的数据管道进行通讯，因而View中显示和操作的数据可以直接从Model获取，MVC形成的是一种三角形的结构形态。

在随后的发展过程中，基于B/S结构的Web应用程序得到了大量地使用，开发人员不得不舍弃了基于连接的稳定可靠的客户端/服务器通讯方式，代之以基于非连接的Http通讯协议。在这种应用环境中，View和Model通常采用不同的语言进行开发，它们之间的数据交互变得比较不容易实现和控制。

在为了适应这种结构开发而出现的应用程序开发框架中，Controller除了实现传统的功能外，还越来越多地被作为View和Model之间进行交互的数据通道。View和Model之间的直接交互被慢慢地断开，MVC逐渐形成了适应Web应用程序开发的双键形态，如图3所示。

从双键结构到MVC链状结构

随着Web应用程序的应用领域不断扩展，应用复杂度不断提高，双键式MVC结构中的每一层都变得更加复杂和难以控制，因而将其直接作为分析和构造依据，就显得略微有些单薄。

由于MVC结构是一种分层结构，合理的层次划分将使其每一层完全可以独立地进行构造，而不影响整个应用程序的结构和功能，这就使递归地使用MVC结构成为可能。

在这种结构中，原来的Model层、Controller层和View层的内部被再次进行层次划分，并用一个更小粒度的MVC结构去实现这种划分。

如在View层中，可以将软件的界面与复杂的显示逻辑分为：View层界面和界面控制器，同时利用上层MVC结构中的控制器作为View层的Model。界面控制器为View层界面完全屏蔽了业务逻辑的具体实现方式，专注于软件显示逻辑的实现，而上层控制器则为整个View层屏蔽了底层的数据访问方式，这就是一个View层的MVC结构，不妨将之称为View-MVC。如图4所示。

图4：View-MVC的结构

正变得越来越复杂的Controller层也可以进行类似的划分和实现，传统的MVC结构中Controller层承担了太多的任务，以至于它成了应用软件在维护和扩展过程中的一个难以控制和把握的硬疙瘩。

图5：Controler-MVC的结构

如果将其实现为如图5所示的Controller-MVC结构，传统的控制器将被分成界面控制器、业务控制器和数据控制器3个部分实现。应用程序的显示逻辑完全由界面控制器来控制，对于业务控制器来说，它就是Controller。而数据控制器封装了所有下层的数据访问过程的具体实现方法，为业务控制器的运行提供Model层的支持。这样就避免了系统的显示逻辑、业务逻辑与数据逻辑的相互纠缠和牵制。

而对于Model层来说，现在绝大多数的Web应用程序中，都会使用一个O/R映射框架，将以关系形式保存在数据库中的数据转换成内存中的数据对象，并通过一个数据访问对象DAO(Data Access Object)向上层应用程序提供数据持久层的访问功能，这种机制本身就可以看做是一个Model-MVC结构，如图6所示。

图6：Model-MVC的结构

运行于内存中的数据对象通过一个固定的机制，将数据库中的数据关系转换成编程语言易于处理的对象的形式，这些就构成了这个结构自身的Model，而数据访问对象就是这个结构的Controller，以上层Controller为代表的数据使用者相当于Model-MVC的View了。

通过上述的结构划分，复杂的Web应用程序被分成3个相对简单的MVC结构来实现，同时各个层次内部的MVC结构中，部件之间的角色也不是固定的，而是相对的。

其中View层中的界面控制器是View-MVC中的控制器，同时也是Controller-MVC中的View，而业务控制器在Controller-MVC中是一个控制器，对于View-MVC来说就是它的Model，对于Model-MVC来说又相当于View。

在实际应用时整个应用会按这些相对的角色连接起来，形成如图7所示的MVC链的形态。这就是由MVC的递归式应用而形成的结构。

MVC链状结构的优势

MVC链状结构中，由于将传统的MVC中的每一个层都以一个较小粒度的MVC结构来实现，从而大大提高了程序的处理能力，使Web应用程序可以支持比以往更多的应用逻辑的运行，这也使Web应用软件能更好地适应不断增长的需求。

在以传统的双键式MVC为分析和构造模式的应用程序中，MVC的应用粒度是达到每个业务对象的具体操作级别的。每个应用程序中可能会存在很多个平行的MVC结构，它们大致是组合/聚合关系，主要通过控制器关联在一起，可形象地称为MVC束。这种结构造成了庞大的文件数量，对这些文件进行管理是一笔不小的开销。因此，在这个尺度上进行直接构造并未能充分体现MVC结构的简单、优雅、灵活与高效。

而递归的MVC结构通过将各个层次分别进行构造，将每个层次的内部逻辑封装在层次内部以一个更小的MVC结构实现，从而形成了一个MVC链的整体结构。

这样就以更加丰富的层次结构复杂性换取了基本构造单元的复杂度，结构复杂性是计算机擅长处理的，基本构造单元却主要依靠人去构造。因而递归地应用MVC，可以通过更丰富的层次划分换取层次之间较低的耦合。这种分析模式已经在有些公司的业务软件开发中被大量使用，并取得了良好的应用效果。

查看本文来源