1、Mediator：中介、介质
2、PureMVC中还有另外一个单例模式类——Façade，Façade提供了与核心层通信的唯一接口，以简化开发复杂度。
3、Proxy：代理
Model保存对Proxy对象的引用，Proxy负责操作数据模型，与远程服务通信存取数据。
这样保证了Model层的可移植性。
4、View保存对Mediator对象的引用。由Mediator对象来操作具体的视图组件（View Component，例如Flex的DataGrid组件），包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。
这样做实现了把视图和控制它的逻辑分离开来。
Notification：通知
5、Controller保存所有Command的映射。Command类是无状态的，只在需要时才被创建。
Command可以获取Proxy对象并与之交互，发送Notification，执行其他的Command。经常用于复杂的或系统范围的操作，如应用程序的“启动”和“关闭”。应用程序的业务逻辑应该在这里实现。
6、Façade 与 Core
Façade类应用单例模式，它负责初始化核心层（Model，View和Controller），并能访问它们的Public方法。
这样，在实际的应用中，你只需继承Façade类创建一个具体的Façade类就可以实现整个MVC模式，并不需要在代码中导入编写Model，View和Controller类。
Proxy、Mediator和Command就可以通过创建的Façade类来相互访问通信。
7、Observer 与 Notification
PureMVC的通信并不采用Flash的EventDispatcher/Event，因为PureMVC可能运行在没有Flash Event和EventDispatcher类的环境中，它的通信是使用观察者模式以一种松耦合的方式来实现的。
你可以不用关心PureMVC的Observer/Notification机制是怎么实现的，它已经在框架内部实现了。你只需要使用一个非常简单的方法从Proxy, Mediator, Command和Facade发送Notification，甚至不需要创建一个Notification实例。
8、Mediator发送、声明、接收Notification
当用View注册Mediator时，Mediator的listNotifications方法会被调用，以数组形式返回该Mediator对象所关心的所有Notification。
之后，当系统其它角色发出同名的Notification（通知）时，关心这个通知的Mediator都会调用handleNotification方法并将Notification以参数传递到方法。
9、Proxy发送，但不接收Notification
在很多场合下Proxy需要发送Notification（通知），比如：Proxy从远程服务接收到数据时，发送Notification告诉系统；或当Proxy的数据被更新时，发送Notification告诉系统。
如果让Proxy也侦听Notification（通知）会导致它和View（视图）层、Controller（控制）层的耦合度太高。
10、Façade：
Façade是Model、View和Controller三者的“经纪人”。实际编写代码时你并不用导入这三者的类文件，也不用直接使用它们。Façade类已经在构造方法包含了对核心MVC三者单例的构造。
一般地，实际的应用程序都有一个Façade子类，这个Façade类对象负责初始化Controller（控制器），建立Command与Notification名之间的映射，并执行一个Command注册所有的Model和View。
Façade类应被当成抽象类, 永远不被直接实例化。针对具体的应用程序，你应该具体编写Façade的子类，添加或重写Façade的方法来实现具体的应用。按照惯例，这个类命名为“ApplicationFacade”（当然，命名随你喜欢），如前所述，它主要负责访问和通知Command，Mediator和Proxy。
通常，不同的运行平台都会创建视图结构，尽管创建过程不一样。（比如Flex中MXML程序负责实例化所有子视图组件，Flash影片在Stage上构建可视对象）。视图结构构建完毕时，整个PureMVC机制也已经安置妥当。
创建的Facade子类也被用来简化“启动”的过程。应用程序调用Facade子类的startup方法，并传递自身的一个引用即完成启动，使得应用程序不需要过多了解PureMVC。