PureMVC
PureMVC Gestalt
特点:
- 在PureMVC实现的经典MVC元设计模式中，MVC的核心元素由三个单例模式类来管理，它们为Model类、View类和Controller类。
- PureMVC还应用了另一个单例模式类Facade作为与核心层通信的唯一接口，以简化开发复杂度。
- Models以Proxies实现，Controllers以Commands实现，Views以Mediators实现。三者之间的通讯采用PureMVC自身的Notification通知响应机制。
- 各个类的具体MVC角色
- Proxies = Model
- Mediator and its ViewComponents = View
- Commands = Controller
Facade and Application entry
顾名思义，Facade是外观模式类，它将MVC的核心三元素组合进自己的对象，以简化程序开发，它是PureMVC应用程序的入口。
职责：
- Façade类对象负责初始化Controller
- 建立Command与Notification名之间的映射
- 执行Command注册所有的Model和View
- PureMVC应用程序的入口和启动点
注意:
除了顶层的Application，其他视图组件都不用（不应该）和Façade交互
实现：
- 实现顶层的Application
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute"
creationComplete="facade.startup(this);">
<mx:Script>
<![CDATA[
private var facade:ApplicationFacade =ApplicationFacade.getInstance();
]]>
</mx:Script>
</mx:Application>
- 使用ApplicationFacade.as模板实现Facade类
Notification
PureMVC使用了观察者模式，所以各层之间通过Notification以松耦合的方式通信，并且与平台无关。
在各层之间的应用:
- Facade 和Proxy只能发送Notification
- Mediators既可以发送也可以接收Notification
- Command也可以发送Notification
- View Component与Mediator，以及Data Object与Proxy的通讯要通过触发Event进行，而不是发送Notification
- Proxy和Mediator之间的交互通过Notification进行，避免它们之间的直接引用
- Notification可以携带是任意Action Script对象的“报体”，在通知中携带着数据，实现各层之间的数据通讯
各层之间的传输路径:
- Mediator -> Mediator
- Mediator -> Command
- Command -> Command
- Command -> Mediator
- Proxy -> Mediator
- Proxy -> Command
Notification和Event常量:
- 应用程序只有少量Notification名称常量时，可以定义在Facade类中
- 当应用程序有大量Notification名称常量时，可以定义ApplicationConstants类来统一管理
- 永远不要把Event的名称常量定义在 Façade类里。应该把Event名称常量定义在那些发送事件的地方，或者就定义在Event类里。
Command
Command对象是无状态的(可以对比Http协议的无状态性)
职责：
1． 注册、删除Mediator、Proxy和Command，或者检查它们是否已经注册。
2． 发送Notification通知Command或Mediator做出响应。
3． 获得Proxy和Mediator对象并直接操作它们。
4． 管理应用程序的业务逻辑。
5． 与Mediator和Proxy交互，应避免Mediator与Proxy直接交互。
实现：
- 在controller包中使用MacroCommand.as模板建立StartupCommand
- 在controller包中使用SimpleCommand.as模板建立ModelPrepCommand，注册Proxy，完成Model的初始化。
- 在controller包中使用SimpleCommand.as模板建立ViewPrepCommand，注册Mediator，完成View的初始化。
- 在Facade中建立Command与Notification名之间的映射
Model and Proxy
Proxy封装了数据模型，管理Data Object及对Data Object的访问。Model通过使用Proxy来保证数据的完整性、一致性 。Proxy集中程序的Domain Logic（域逻辑），并对外公布操作数据对象的API。它封装了所有对数据模型的操作，不管数据是客户端还是服务器端的，对程序其他部分来说就是数据的访问是同步还是异步的。
Proxy Pattern分类:
- Remote Proxy，当Proxy管理的数据存放在远程终端，通过某种服务访问。
2．Proxy and Delegate，多个Proxy共享对一个服务的访问，由Delegate封装对服务的控制访问，确保响应正确的返回给相应的请求者。
3．Protection Proxy，用于数据对象的访问有不同的权限时。
4．Virtual Proxy，对创建开销很大的数据对象进行管理。
5．Smart Proxy，首次访问时载入数据对象到内存，并计算它被引用的次数，允许锁定确保其他对象不能修改。
实现：
- 在model包中使用模板Proxy.as或RemoteProxy.as建立Proxy类
- 在Command中注册Proxy
- 获得并转换数据对象，另外，可能需要定义不同的多个类型getter来取得Data Object某部分的数据。
public function get searchResultAC () : ArrayCollection
{
return data as ArrayCollection;
}
public function get resultEntry( index:int ) : SearchResultVO
{
return searchResultAC.getItemAt( index ) as SearchResultVO;
}
Mediator
Mediator是视图组件与系统其他部分交互的中介器，它封装View component(它们之间的内部交互通过View Component派发的Event事件)，它通过发送和接收Notification来与程序其他部分通讯。
职责：
- 处理View Component派发的Event事件
- 接收并处理系统其他部分发出来的Notification
- Mediator会经常和Proxy交互，所以经常在Mediator的构造方法中取得Proxy实例的引用并保存在Mediator的属性中，这样避免频繁的获取Proxy实例。
- 发送Notification，与系统的其他部分交互
实现：
- 在View包中使用Mediator.as模板建立ApplicationMediator
- 在Command中注册Mediator，如果有多个Mediator的话，最好只在Command中注册ApplicationMediator，其他Mediator的注册在ApplicationMediator中进行
- 获得并转换View Component类型
- 监听View Component派发出来的Event事件
- 添加Mediator感兴趣的Notification
- 处理Event和Notification
protected function get controlBar() : MyAppControlBar
{
return viewComponent as MyAppControlBar;
}
注意:
- 处理Notification的方法不应该负责复杂逻辑，复杂的业务逻辑由Command完成。
- Mediator处理的Notification应该在4、5个之内，如果处理的Notification很多，则意味着Mediator需要被拆分，在拆分后的子模块的Mediator里处理要比全部放在一起更好。
- 处理Event和Notification的方法一般都应该很简单