PureMVC

PureMVC

PureMVC Gestalt

 

特点:

1. 在PureMVC实现的经典MVC元设计模式中，MVC的核心元素由三个单例模式类来管理，它们为Model类、View类和Controller类。
2. PureMVC还应用了另一个单例模式类Facade作为与核心层通信的唯一接口，以简化开发复杂度。
3. Models以Proxies实现，Controllers以Commands实现，Views以Mediators实现。三者之间的通讯采用PureMVC自身的Notification通知响应机制。
4. 各个类的具体MVC角色

   - Proxies = Model
   - Mediator and its ViewComponents = View
   - Commands = Controller

 

 

Facade and Application entry

 

顾名思义，Facade是外观模式类，它将MVC的核心三元素组合进自己的对象，以简化程序开发，它是PureMVC应用程序的入口。

职责：

1. Façade类对象负责初始化Controller
2. 建立Command与Notification名之间的映射
3. 执行Command注册所有的Model和View
4. PureMVC应用程序的入口和启动点

注意:

除了顶层的Application，其他视图组件都不用（不应该）和Façade交互

实现：

1. 实现顶层的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>

1. 使用ApplicationFacade.as模板实现Facade类

Notification

 

PureMVC使用了观察者模式，所以各层之间通过Notification以松耦合的方式通信，并且与平台无关。

在各层之间的应用:

1. Facade 和Proxy只能发送Notification
2. Mediators既可以发送也可以接收Notification
3. Command也可以发送Notification
4. View Component与Mediator，以及Data Object与Proxy的通讯要通过触发Event进行，而不是发送Notification
5. Proxy和Mediator之间的交互通过Notification进行，避免它们之间的直接引用
6. Notification可以携带是任意Action Script对象的“报体”，在通知中携带着数据，实现各层之间的数据通讯

各层之间的传输路径:

• Mediator -> Mediator
• Mediator -> Command
• Command -> Command
• Command -> Mediator
• Proxy -> Mediator
• Proxy -> Command

 

Notification和Event常量:

1. 应用程序只有少量Notification名称常量时，可以定义在Facade类中
2. 当应用程序有大量Notification名称常量时，可以定义ApplicationConstants类来统一管理
3. 永远不要把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直接交互。

 

实现：

1. 在controller包中使用MacroCommand.as模板建立StartupCommand
2. 在controller包中使用SimpleCommand.as模板建立ModelPrepCommand，注册Proxy，完成Model的初始化。
3. 在controller包中使用SimpleCommand.as模板建立ViewPrepCommand，注册Mediator，完成View的初始化。
4. 在Facade中建立Command与Notification名之间的映射

 

 

Model and Proxy

 

Proxy封装了数据模型，管理Data Object及对Data Object的访问。Model通过使用Proxy来保证数据的完整性、一致性 。Proxy集中程序的Domain Logic（域逻辑），并对外公布操作数据对象的API。它封装了所有对数据模型的操作，不管数据是客户端还是服务器端的，对程序其他部分来说就是数据的访问是同步还是异步的。

 

Proxy Pattern分类:

1. Remote Proxy，当Proxy管理的数据存放在远程终端，通过某种服务访问。

2．Proxy and Delegate，多个Proxy共享对一个服务的访问，由Delegate封装对服务的控制访问，确保响应正确的返回给相应的请求者。

3．Protection Proxy，用于数据对象的访问有不同的权限时。

4．Virtual Proxy，对创建开销很大的数据对象进行管理。

5．Smart Proxy，首次访问时载入数据对象到内存，并计算它被引用的次数，允许锁定确保其他对象不能修改。

 

实现：

1. 在model包中使用模板Proxy.as或RemoteProxy.as建立Proxy类
2. 在Command中注册Proxy
3. 获得并转换数据对象，另外，可能需要定义不同的多个类型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来与程序其他部分通讯。

 

职责：

1. 处理View Component派发的Event事件
2. 接收并处理系统其他部分发出来的Notification
3. Mediator会经常和Proxy交互，所以经常在Mediator的构造方法中取得Proxy实例的引用并保存在Mediator的属性中，这样避免频繁的获取Proxy实例。
4. 发送Notification，与系统的其他部分交互

 

实现：

1. 在View包中使用Mediator.as模板建立ApplicationMediator
2. 在Command中注册Mediator，如果有多个Mediator的话，最好只在Command中注册ApplicationMediator，其他Mediator的注册在ApplicationMediator中进行
3. 获得并转换View Component类型
4. 监听View Component派发出来的Event事件
5. 添加Mediator感兴趣的Notification
6. 处理Event和Notification

     protected function get controlBar() : MyAppControlBar

{

return viewComponent as MyAppControlBar;

}

 

注意:

1. 处理Notification的方法不应该负责复杂逻辑，复杂的业务逻辑由Command完成。
2. Mediator处理的Notification应该在4、5个之内，如果处理的Notification很多，则意味着Mediator需要被拆分，在拆分后的子模块的Mediator里处理要比全部放在一起更好。
3. 处理Event和Notification的方法一般都应该很简单