作者 Moxie Zhang译者 郭晓刚 发布于 2008年7月4日 上午1时7分

富有经验的Java开发者Per Olesen在Tech Per上发了一篇博客文章，比较两个最流行的flex框架，PureMVC 和Cairngorm，并且着重比较了可用性和它们对GUI架构模式的应用。

在开发中以设计模式为指导已经是Java开发者的基本技术。在flex和ActionScript开发者当中，设计模式的实践要么是从Java开发经验中来的，要么就是由一些ActionScript/Flex框架带来的。Olesen描述了这个过程：

为了帮助架构这类应用，发展出了一些GUI架构的模式。其中一些比较著名的模式，Martin Fowler已经作了很好的描述，比如a href="http://martinfowler.com/eaaDev/PresentationModel.html">Presentation Model（呈现模型）和Supervising Presenter。它们不是像MVC一样完整的用户界面架构，而是一些比较小的架构指引，涉及的是应用程序的逻辑如何与视图框架的API联系起来。

他解释说：

PureMVC有一个名为Mediator的构造，顾名思义，它就是Mediator模式的实现，充当视图API和程序其余部分的API之间的中介。这是PureMVC实现MVC架构视图部分的关键构造。引入它是为了减少应用和视图之间的依赖，从而降低整个系统的耦合程度。

Olesen还指出PureMVC有一份关于实现之惯例和最佳实践的文档，文档中还以实际的例子LoginPanel进行解说。在例子里可以看出，只有mediator了解视图，视图对mediator一无所知。

在分析了PureMVC的文档提供的源代码之后，Olesen相信这个其实就是Supervising Presenter模式或者Passive View（被动视图）模式。两种模式都把行为从视图中抽出来，将之放入与视图耦合的一个表现类。在两个模式中，都是“表现者知道视图，视图不知道表现者 ”。因此两种模式的区别在于如何抽取逻辑。PureMVC的mediator与Supervising Presenter最为接近。

谈到Cairngorm框架，Olesen的观察是：

Cairngorm没有mediator、supervising presenter,或者passive view的概念。实际上批评它的人很多，因为它鼓吹的方案是将视图组件的状态直接绑定到模型。但更糟的问题是模型只是通过单体模式表达的一个全局状态。

在Cairngorm文档和例子（无论是简单的联系人管理程序还是比较复杂的Cairngorm Store）中，这个问题更加突出。视图中有许多逻辑，而且是按照Autonomous View（自治视图）模式来安排的。什么是Autonomous View模式呢？Martin Fowler的回答是：将一个窗口所有的表现状态和行为都放在一个类里。

Olesen觉得这种模式等于是没有模式。他觉得采用Cairngorm的应用程序里的自治视图是在鼓励直接把数据绑定到一个全局模型的实例上，非常不利于分离视图和模型两者的关注点。

最后，Olesen并非简单地认为这个框架比那个好，他的结论是：

无论是哪个框架，UI模式都只是框架的一部分，虽然是重要的一部分。有人会觉得PureMVC自带的东西更多一些，mediator是框架中内建的概念。中介者及以通知方式进出中介者的通信，都很好地整合进了PureMVC框架。

查看英文原文：Comparing GUI Patterns in PureMVC and Cairngorm