一、简介
一般应用中用户界面的变化相对较为频繁 ， 有时需要支持多种表现模式（如 WEB 客户端和 GUI 客户端），但是数据和业务逻辑相对保持稳定。
MVC（Model-View-Controller） 模式是一种常用的设计模式 ，MVC 将模型 ， 显示和控制进行了分离，可以使得应用更加方便实现对多种表现模式的支持及降低表现形式修改对整体系统的影响。由于本文重点讨论的是 MVC 中的通知机制，至于 MVC 的其它内容可以参考其它相关文档。
图表一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
作者：
蔡超，贵州大学，计算机软件与理论，硕士
