Flex PureMVC 简单分析

项目需要，对PureMVC进行了一些研究， 分析了一下结构和流程，贴出来希望大家指正错误。

1结构

[img]http://i3.6.cn/cvbnm/a5/bb/9d/b0045f3a06a19691e713e8f6f85ccd90.jpg[/img]

总的来说是把传统的MVC三层，利用Observer和Command模式进行了解耦
View、Control、Model也细化成：UI、Mediator、Command、ModelProxy、Model。另外ApplicationFacade负责配置模块之间的映射关系和初始化

2流程

蓝色箭头：表示初始化时做的注册、映射等操作
黑色箭头：表示职责
红色箭头：一个用户操作产生后的代码流程。


[img]http://i3.6.cn/cvbnm/14/a6/1d/ede8876f6be85111ccf6001c9bafea22.jpg[/img]

A 在视图和控制层之间，利用Flex自带的Event机制，通过Dispatch和Listener实现解耦。

Detail：UI为一个MXML，并对应一个Mediator，可以称为中介。UI中的组件只负责通过 click=" dispatchEvent(new Event(CREATE, true))" 的方式抛出事件。
Mediator 为UI中抛出的各个事件注册并实现监听函数。

B 在控制层和model（Service）层之间，利用PureMVC自己实现的Notification机制，发送出Notification，映射到Command执行业务代码，实现解耦。

Detail： 视图对应的Mediator接收到视图抛出的event后，进行预处理，将数据包装成Notification，调用PureMVC的Notification接口将通知发送出去，每个Notification都会通过配置，映射到Command。 Command执行过程中可以调用ModelProxy（实体代理）中的Service。ModelProxy中的Service负责与后台通信（调用后台RemoteObject或者发送HTTP Service等）并维护Model。异步返回结果会调用Command中的Result或Fault方法。此时Command可以继续发送Notification启动下一个Command。
另外一个比较关键的环节是，对于每个Notification，PureMVC不仅会映射到Command并执行，而且Mediator中也可以通过实现handleNotification接口来接收该通知并进行处理。


另外，关于项目的初始化， 过程在这里单独描述一下，因为它也是利用这个流程。 项目的Applicaiton MXML作为程序入口，需要产生一个Application Facade实例，产生的过程中ApplicationFacade会完成Notification和Command的映射，然后Application MXML发送一个“Initialize”之类的初始化Notification，通过刚完成的映射，一个初始化命令会产生并执行（InitAppCommand），在这个命令中可以进行系统初始化操作，以及完成UI和Mediator的映射。


总结：
具体的过程和以往的MVC解耦方法类似，都是通过观察者模式+命令模式，也有点像Eclipse插件开发的GEF开发。

其中Mediator作为视图的中介， 在视图和控制的解耦中起到比较关键的作用。 而且handleNotification的接口设计也很到位。根据分析的几个项目代码，直接控制UI显示的代码大部分是在这个接口中实现。 也就是将Control分成了两种，UI相关的Control（Mediator负责），和业务相关的Control（Command负责）。这样各部分职责更加清晰。

另外Mediator控制UI显示也提倡通过维护Bindable数据来实现。


至于缺点的话，有一点是很明显的， 那就是配置映射关系的代码。 这里没有贴出映射代码，但是看到这里大家应该也看出来PureMVC的流程是很依赖映射关系的
1 UI和Mediator的映射（InitAppCommand中）
2 UI抛出的Event和Mediator的监听函数映射（Mediator中）
3 Notification和Command的映射。（ApplicaitonFacade中）

这三种配置必然会随着项目的规模而膨胀。需要细心控制和维护。

另外使用Notification机制总有种兜圈子的感觉， 虽然模块划分更清晰，功能职责更细化，但一些本来简单的逻辑也会带出自己的Notification和Command，Command的粒度问题也需要考虑。