MVC新应用 递归的结构

从双键结构到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，可以通过更丰富的层次划分换取层次之间较低的耦合。这种分析模式已经在有些公司的业务软件开发中被大量使用，并取得了良好的应用效果。

查看本文来源