富有经验的 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 框架。
评论