总结PureMVC中Mediator,Command,Proxy的职责
我对PureMVC的喜爱可以说到了偏执的地步...我知道这样不好 。当我第一次接触它时，我就被它简洁轻量的架构所迷住，因为十分符合我个人的编码习惯了，一切从简，于是乎，之后无论公司或个人的项目 ，都用到了PureMVC，我知道这样也不好，但我就是偏执！说的有点跑题了..归入正题，我们知道，PureMVC由3个单例模式类组成，分别是Model,View和Controller，可以说这3层就是整个PureMVC的核心。那么这3层在框架 中各自扮演着什么样的角色和其职责呢？下面总结一下。（住：示例代码 片段全部来自PureMVC官网中的练习示例,代码中被星号框起来的为要点）
Mediator （注：Component为视图组件 ）
发送 Notification
在Mediator中可以发送Notification与其他Mediator进行通信 ，或者触发一个Command。
SliderMediator.as
监听 Notification
Mediator会列出自身所侦听的Notifications，然后根据接收到的不同Notification来设置视图组件的数据 或调用其方法，改变其状态。
ApplicationMediator.as
监听 Component自身的事件 并将事件转化为Notification
Mediator可以侦听来自于视图组件的Flash Event事件，有必要的话，可以将其转化为 Notification
DateFieldMediator.as
设置Component的数据
在 Mediator中可以设置视图组件中的数据。
ApplicationMeiator.as
调用 Component的方法
在Mediator中可以调用试图组建中的方法函数以改变视图组件的状态。
VideoMediator.as
可以创建其他Mediator
在 Mediator中可以创建其他Mediator，例如一个容器需要一个子容器，这时就可以在当前容器Mediator下创建一个新的子容器Mediator，传入父容器视图即可。
ColorfulViewStackMediator.as
可以直接获得Proxy并调用其公开的属性 和方法
在Mediator中可以方便的直接操纵Model。但假如有多个Mediators都指向同一个Proxy，那最好写一个Command来代替。
BlueViewMediator.as
Command
发送 Notification
Command可以发送Notification给Mediator，或者触发其他Command.
StartupCommand.as
允许注册，获得和删除Proxy与Mediator
Command可以在运行时进行注册，获得和删除指定的Proxy与Mediator。
ViewPrepCommand.as
可以同时处理多个Proxy
其实就是在Command中实现业务逻辑，因为有时候可能需要多个数据进行一系列的复杂操作，这些业务逻辑都应该放在Command里实现。
Proxy
只发送但不接收 Notification
好多情况下Proxy都需要发送Notification，比如说负责远端数据的Proxy当数据有更新时就需要发送一个Notification告诉整个系统说：“数据更新了，有关系的赶紧起来做事了”。Proxy永远不会接收Notification。
RssProxy.as
可以和其他Proxy相通信
在 Proxy中，可以注册，获得和删除其他的Proxy。有时我们可以将多个Proxy按照一定的结构层次来进行互通。
CarOwnersProxy.as
与后台连接
Proxy可以与远端服务器进行连接于并接收数据。
RssProxy.as
好了，大体就总结这么多，希望对大家有所帮助。很多人对在Mediator里可以操作Proxy表示不解，因为这无形中增加了两者的依赖关系，违背了松耦 合的理念，官文文档也表示尽量少用这种方法而应该放入Command去操作，那这种方式的存在究竟是为什么呢？接下来会再发一个帖子专门讨论这个问题。