PureMVC
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的方法一般都应该很简单
posted on 2010-05-15 09:04 God bless you 阅读(589) 评论(0) 编辑 收藏 举报