PureMVC如果要实现一个功能 哪怕很简单, 要写的类实在太多了. 比如需要打开一个人物信息面板, 流程大致如下:
showUserInfoBtn CLICK事件 -> Meidator侦听该事件发送通知 -> GetUserInfoCommand (Proxy获取人物信息面板数据) ->
获取成功 / 失败 发送通知 -> GetUserInfoSuccessCommand/GetUserInfoFailCommand -> 发送通知给Mediator刷新面板显示.
Proxy也可以直接发通知给Mediator, 但是为了让view与model的彻底分离, 官方不推荐这样的做法.
其实看了上面的流程会发现, GetUserInfoCommand其实和Proxy是紧耦合的, 如果Proxy与GetUserInfoSuccessCommand/GetUserInfoFailCommand
算是组合关系, 既然这样为什么不让Mediator直接调用Proxy? 很多人都说这样就会使得View与model的耦合性增加, 当然, 如果让Mediator直接调用Proxy, 并且
根据这个Proxy来获取数据的话的确增加它们俩之间的耦合, 如果Proxy分为两部分: 数据处理(DataManager)和数据通知发送. 数据处理部分主要负责一个数据池,
这个数据池放入了所有从服务端获取的数据, 这个数据对于flash本地来说只能读取不能写入, 要实现删除数据和修改数据是由服务端来控制. 数据通知部分就好比是
请求结束后的两个Command. 这样一来Proxy就像一个工具, 如果需要用到某个工具, 这个工具已经封装好, 它封装了行为(请求某个数据)和结果(成功后会影响到的
结果, 发送相应的通知). 无论是什么地方需要用到这个工具, new一个出来然后send()一下就可以了. 其他的均不用考虑, Mediator只需要做好对通知的相应处理即可.
还有一个小小的好处就是不用写vo, Proxy子类在构造函数中写上需要的参数, 编写代码会明确很多, 也方便多人开发(不用编写数据请求格式约定文档, 当然与后台的
约定文档还是要的).
对于Command, 我发觉很多人都很喜欢写Command, 一眼望去满满的Command类, 可能自己有点不喜欢这样吧, 一开始写了很多, 后来发觉很多的Command都是
可以整合在一起的, 比如打开一个面板和关闭一个面板, Command不一定是一个具体的命令, 而应该是宏, 这样可以少写很多Command .
Mediator, 中介者, 我一直在想这个Mediator到底中介谁, 是Command/Proxy, 还是ui与ui之间? 官方说Mediator可以管理几个ui, 可是在项目中我没用到过一个
Mediator管理几个ui的地方, 加上Mediator需要传入一个view的对象, 每次界面需要请求数据都要发送事件给Mediator, 让Mediator来请求, 这样是不是多了一步? 为什么
不能让ui直接请求呢 ? 因为Mediator与ui之间本身就是紧耦合的, 而且它们俩基本上动一个另外一个也需要修改(除非ui接口不变, Mediator只改变发送通知和调用api的地方),
而实际上一旦ui发生了变化, 比如多了一个元素, 那么Mediator就可能需要改变的地方是: 增加一个事件, 增加一个通知, 根据这个通知ui可能也需要增加一个刷新ui的接口.
因此我将ui与Mediator合为了一个view, view是可显示对象, 继承自sprite, 当被添加到舞台时自动注册,移除时自动取消注册. 这样的好处: 省掉了一堆的事件类, 省掉了VO,
省掉了Mediator(其实是把Mediator的处理通知的地方放进了ui). 对于ui来说, 只是多了Mediator中可以接收的通知列表, 和对每一个通知的反映. ui与ui之间是完全解耦的,
ui甚至没有对外的接口, 因为外部没有需要调用的地方.
Mediator与ui怎么整合在一起呢, 看了PureMVC的源代码后会发现,
facade这个外观的Command相关的行为(注册/取消注册/判断是否已注册等)其实是调用了Controller来注册, Controller是调用View来注册.
Mediator相关行为是View来注册.
Proxy的相关行为是Model来管理, 在Model内部调用的还是View的方法.
我的写法是:
Command的行为由CommandManager来管理, View由ViewManager来管理. Model不存在, 被分离为一个Proxy作为一个独立的部分.
CommandManager和ViewManager都是单例, 都是由ObserverManager来管理注册等行为. 之所以把View的功能给分出来, 是因为我想把View
继承自显示对象, 让它实现通知的接收和发布功能.