PureMVC的十个小提示
用(Pure)MVC的思想去思考
我应该如何开始使用(Pure)MVC呢? 一句话:用(Pure)MVC的思想去思考! 从它的名字中就可以看出, PureMVC 是基于一般的 Model-View-Controller 元设计模式的.使用Facade-pattern 这种模式你不需要直接初始化一个核心行为(instantiate the core actors), 但是PureMVC中的每个Class都有它自己的定义很清楚的角色:
- Proxies = Model
- Mediator and its ViewComponents = View
- Commands = Controller
为View Components创建API
一个 View Component可能是一个标准的UI component (比如DataGrid) 或者自定义组件 (比如一个游戏世界) 或者其他的东西. 不要直接使用它的 public方法. 而是把改变它的状态或者行为(等允许被外部调用的各种方法属性)写成API.
PureMVC的一个有点就是可以与所使用的技术无关. 举个例子:我建了一个基于PureMVC的'Pure' Flash application ,没有用到Flex Framework. 而后,为了使用AIR里面的File System API这个Application被转成一个AIR application.这时只需将View Components转化为使用 Flex Framework即可, 其他的Mediators 或者任何PureMVC中的任何actors均不需改变 .
多个View Components共同使用一个Mediator
为了紧密协调多个View Components 仅使用一个Mediator. 换句话说: 不是所有的Views 都需要Mediator. 例如: 有一个ApplicationControlBar,其中包含一个TextInput ,一个Button 或者其他的组件. 然后为ApplicationControlBar 创建一个名为ApplicationControlBarMediator的 Mediator 并且把它指定给ApplicationControlBar中所包含的所有View Component.
让Events bubble up起来
如果你不想在一个Mediator中用多个View Components 又会怎样呢?为了处理多个 View Components的用户交互事件, 我们必须把View Component里面嵌套的所有组件的事件bubble up起来.
例如: 当你点击View Component 里面的任意Button都会触发Mediator监听的一个自定义事件. 所以Mediator并不需要知道这个Button是否存在或者任何一个这个 View Component的其他Child,它只需要知道这个事件已经被触发了就可以.
尽可能地的用Notifications通信
Notifications是PureMVC 里面的“Events” . 当Model, View and Controller 三者之间的通信是下面几种情况时应该尽可能地的使用这个Notifications :
(通信 from -> to)
- Mediator -> Proxy (via mapped Commands)
- Proxy -> Mediator
- Proxy -> Command
- Commands -> Mediator
即使可以从Mediator获得Proxy,也不要直接用Mediator来改变Proxy.应该是用一个mapped Command来发送Notification. 不通过使用Command (Controller)而用Mediator (View)来直接改变 Proxy (Model) 是一种非常糟糕的方法.
尽可能多的使用 Commands / MacroCommands
Commands在控制端做这些工作: Retrieving and interacting Proxies, 与Mediators通信或者执行其他Commands. 即使一个Command仅被用了一次或者只有两行代码也要尽可能多的使用它. 为了在你的Application中可以随时随地的再次执行一个Command ,仅需发送一个Notification.以后也可以很容易的用更复杂的actions来扩展这个 Command. 还有非常重要的一点就是你总是知道改变Proxy (Model)的actor是哪一个.
问题: 你也没有遇到过需要按照特定次序执行多个Command的情况呢? 使用MacroCommands可以顺序执行多个SubCommands (也就是 “简单” Commands) .
使用Remote Proxy来接收和发送服务端数据
在Application中的发送和接收数据的Proxies 叫做“Remote Proxies”. 它不是一种特殊的PureMVC Proxy, 只是一个基于Proxy的location,而这个Proxy是负责处理比如HTTPSerivice,RemoteObject或者其他服务端调用的Proxy.
例如: 为了调用服务器端一个负责登录用户的RemoteObject 而创建了一个叫做LoginProxy的Proxy. LoginProxy负责所有与服务器端通信的工作, 也就是接收和发送数据. 当你为LoginProcess改变服务器端执行操作时,你值需要改变Application中的一个locationt即可,即 LoginProxy.
去掉没有用到的Mediators
在某些情况下你不再使用一个Mediator和它的View Components. 你应该用facade.removeMediator(MyMediator.NAME)去掉这个Mediator同时用 destroy()来去掉包含所有listeners,timer,references的ViewComponent.以便更好的进行 垃圾回收.
VO's (Value Objects)的魅力所在
当然在Model中存放数据的是Proxies. 而且View Components不需要知道Facade和这个PureMVC application的其他部分. 这就意味着View Component不会直接访问Model的数据.
为了避免在View Component中存放数据可以使用一个 名为Value Objects (VO’s)的引用 . VO's并不是PureMVC里面的核心actor,它和Flex里面的Data Binding有点渊源,是一个可以在不打破规则的情况下改变Model的数据的非常强大的方法..
可以找到的课件
Cliff Hall 做个一个值得敬畏的工作: 不仅有非常好的文档 “Framework Overview“, “Best Practices” and a “Conceptual Diagram“, 而且还有非常非常有用的 课件. 自己去看看吧!
我应该如何开始使用(Pure)MVC呢? 一句话:用(Pure)MVC的思想去思考! 从它的名字中就可以看出, PureMVC 是基于一般的 Model-View-Controller 元设计模式的.使用Facade-pattern 这种模式你不需要直接初始化一个核心行为(instantiate the core actors), 但是PureMVC中的每个Class都有它自己的定义很清楚的角色:
- Proxies = Model
- Mediator and its ViewComponents = View
- Commands = Controller
为View Components创建API
一个 View Component可能是一个标准的UI component (比如DataGrid) 或者自定义组件 (比如一个游戏世界) 或者其他的东西. 不要直接使用它的 public方法. 而是把改变它的状态或者行为(等允许被外部调用的各种方法属性)写成API.
PureMVC的一个有点就是可以与所使用的技术无关. 举个例子:我建了一个基于PureMVC的'Pure' Flash application ,没有用到Flex Framework. 而后,为了使用AIR里面的File System API这个Application被转成一个AIR application.这时只需将View Components转化为使用 Flex Framework即可, 其他的Mediators 或者任何PureMVC中的任何actors均不需改变 .
多个View Components共同使用一个Mediator
为了紧密协调多个View Components 仅使用一个Mediator. 换句话说: 不是所有的Views 都需要Mediator. 例如: 有一个ApplicationControlBar,其中包含一个TextInput ,一个Button 或者其他的组件. 然后为ApplicationControlBar 创建一个名为ApplicationControlBarMediator的 Mediator 并且把它指定给ApplicationControlBar中所包含的所有View Component.
让Events bubble up起来
如果你不想在一个Mediator中用多个View Components 又会怎样呢?为了处理多个 View Components的用户交互事件, 我们必须把View Component里面嵌套的所有组件的事件bubble up起来.
例如: 当你点击View Component 里面的任意Button都会触发Mediator监听的一个自定义事件. 所以Mediator并不需要知道这个Button是否存在或者任何一个这个 View Component的其他Child,它只需要知道这个事件已经被触发了就可以.
尽可能地的用Notifications通信
Notifications是PureMVC 里面的“Events” . 当Model, View and Controller 三者之间的通信是下面几种情况时应该尽可能地的使用这个Notifications :
(通信 from -> to)
- Mediator -> Proxy (via mapped Commands)
- Proxy -> Mediator
- Proxy -> Command
- Commands -> Mediator
即使可以从Mediator获得Proxy,也不要直接用Mediator来改变Proxy.应该是用一个mapped Command来发送Notification. 不通过使用Command (Controller)而用Mediator (View)来直接改变 Proxy (Model) 是一种非常糟糕的方法.
尽可能多的使用 Commands / MacroCommands
Commands在控制端做这些工作: Retrieving and interacting Proxies, 与Mediators通信或者执行其他Commands. 即使一个Command仅被用了一次或者只有两行代码也要尽可能多的使用它. 为了在你的Application中可以随时随地的再次执行一个Command ,仅需发送一个Notification.以后也可以很容易的用更复杂的actions来扩展这个 Command. 还有非常重要的一点就是你总是知道改变Proxy (Model)的actor是哪一个.
问题: 你也没有遇到过需要按照特定次序执行多个Command的情况呢? 使用MacroCommands可以顺序执行多个SubCommands (也就是 “简单” Commands) .
使用Remote Proxy来接收和发送服务端数据
在Application中的发送和接收数据的Proxies 叫做“Remote Proxies”. 它不是一种特殊的PureMVC Proxy, 只是一个基于Proxy的location,而这个Proxy是负责处理比如HTTPSerivice,RemoteObject或者其他服务端调用的Proxy.
例如: 为了调用服务器端一个负责登录用户的RemoteObject 而创建了一个叫做LoginProxy的Proxy. LoginProxy负责所有与服务器端通信的工作, 也就是接收和发送数据. 当你为LoginProcess改变服务器端执行操作时,你值需要改变Application中的一个locationt即可,即 LoginProxy.
去掉没有用到的Mediators
在某些情况下你不再使用一个Mediator和它的View Components. 你应该用facade.removeMediator(MyMediator.NAME)去掉这个Mediator同时用 destroy()来去掉包含所有listeners,timer,references的ViewComponent.以便更好的进行 垃圾回收.
VO's (Value Objects)的魅力所在
当然在Model中存放数据的是Proxies. 而且View Components不需要知道Facade和这个PureMVC application的其他部分. 这就意味着View Component不会直接访问Model的数据.
为了避免在View Component中存放数据可以使用一个 名为Value Objects (VO’s)的引用 . VO's并不是PureMVC里面的核心actor,它和Flex里面的Data Binding有点渊源,是一个可以在不打破规则的情况下改变Model的数据的非常强大的方法..
可以找到的课件
Cliff Hall 做个一个值得敬畏的工作: 不仅有非常好的文档 “Framework Overview“, “Best Practices” and a “Conceptual Diagram“, 而且还有非常非常有用的 课件. 自己去看看吧!