关于MVC模式中的通知机制

一、简介

一般应用中用户界面的变化相对较为频繁，有时需要支持多种表现模式（如WEB客户端和GUI客户端），但是数据和业务逻辑相对保持稳定。

MVC（Model-View-Controller）模式是一种常用的设计模式。MVC将模型、显示和控制进行了分离，可以使得应用更加方便，实现对多种表现模式的支持及降低表现形式修改对整体系统的影响。由于本文重点讨论的是MVC中的通知机制，至于MVC的其它内容可以参考其它相关文档。

 

图表1：MVC模式

二、MVC的通知机制

上图是在SUN的J2EE BluePrints中关于MVC模式的描述，在实现MVC模式时首先应该注意的是模型与视图之间的关系。在这些关系中尤其值得大家注意的是模型通知视图，如果不能正确的设计这个通知机制（模型与视图之间关联实现通知）便会完全违背MVC的设计初衷。MVC模式的其中一个目的在于使模式独立与视图，然而不正确的理解和设计通知机制会导致模型和试图的依赖性。

2.1采用Observer模式实现通知机制

既要实现模式到视图的通知机制，同时又要确保实现模型与视图的分离。通常我们可以通过Observer模式来实现这样的通知机制。

图表2：Observer模式

视图实现Observer接口，并向模型注册，模型通过调用所维护的观察者的实例调用Update方法来通知视图进行刷新。可见，Observer接口有效的实现了模型和视图间的耦合性的分离。

2.2模型通知视图还是控制器通知视图

 

图3：基于MVC的J2EE 应用

在将MVC模式应用于的总体结构时，常常会有是模型通知视图还是控制器通知视图的问题，其实我认为这个问题完全取决于对系统各个部分的划分和理解，如果我们把模型层更多划分为数据实体（如：Entity Bean）则可能会发现，其实我们的通知机制是不能由模型部分来完成的，而是由我们的控制器来完成的。

这种划分好象有些违背了MVC模式，但事实上特别是一些想要同时支持B/S和C/S的J2EE应用，控制器和模式通知机制常常有较大的耦合性（C/S结构中，客户完全通过会话Bean来完成业务），可能有时在一起实现更好。

总之，更好的内聚性和更松散的耦合性才是架构设计的重点，应该做出适合自身应用的MVC架构。

三、结束语

MVC模式的关键在于分离易变和不易变部分间的耦合性，所以在应用MVC模式时一定要注意解耦才是关键，同时一定要更据具体的使用环境进行调整，不要生搬硬套，如Microsoft的MFC采用的Document-view就是MVC的变体，它把控制器合并到视图中，这是因为考虑了视图与控制器紧耦合的影响。

参考文献
1、Sun Microsystem，J2EE BluePrints
2、GOF,Design Patterns, 机械工业出版社，2002

作者

蔡超，贵州大学，计算机软件与理论，硕士
MCSD，SCJP，高级程序员认证
北京天融信网络安全技术有限公司，软件工程师
从事软件开发4年