简介

初始化

运行时候

优缺点(优点 缺点)

简介

Pure MVC是在基于模型、视图和控制器MVC模式建立的一个轻量级的应用框架，这种开源框架是免费的，它最初是执行的ActionScript 3语言使用的Adobe Flex、Flash和AIR，现在已经移植到几乎所有主要的发展平台，目前支持两个版本框架：标准和多核，总之，标准版提供了一种简单的编码分离的方法，按照MVC设计概念。除此之外，多版本允许多个PureMVC应用运行在同一个虚拟机；模块化编程

在PureMVC实现的经典MVC元设计模式中，这三部分由三个单例模式类管理，分别是Model、View和Controller。三者合称为核心层或核心角色。

PureMVC中还有另外一个单例模式类——Facade，Facade提供了与核心层通信的唯一接口，以简化开发复杂度。

Model 与 Proxy

Model保存对Proxy对象的引用，Proxy负责操作数据模型，与远程服务通信存取数据。

这样保证了Model层的可移植性。

View 与 Mediator

View保存对Mediator对象的引用。由Mediator对象来操作具体的视图组件（View Component，例如Flex的DataGrid组件），包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。

这样做实现了把视图和控制它的逻辑分离开来。

Controller 与 Command

Controller保存所有Command的映射。Command类是无状态的，只在需要时才被创建。

Command可以获取Proxy对象并与之交互，发送Notification，执行其他的Command。经常用于复杂的或系统范围的操作，如应用程序的“启动”和“关闭”。应用程序的业务逻辑应该在这里实现。

Facade 与 Core

Facade类应用单例模式，它负责初始化核心层（Model，View和Controller），并能访问它们的Public方法。

这样，在实际的应用中，你只需继承Facade类创建一个具体的Facade类就可以实现整个MVC模式，并不需要在代码中导入编写Model，View和Controller类。

Proxy、Mediator和Command就可以通过创建的Facade类来相互访问通信。

Observer 与 Notification

PureMVC的通信并不采用Flash的EventDispatcher/Event，因为PureMVC可能运行在没有Flash Event和EventDispatcher类的环境中，它的通信是使用观察者模式以一种松耦合的方式来实现的。

你可以不用关心PureMVC的Observer/Notification机制是怎么实现的，它已经在框架内部实现了。你只需要使用一个非常简单的方法从Proxy, Mediator, Command和Facade发送Notification，甚至不需要创建一个Notification实例。

Notification可以被用来触发Command的执行

Facade保存了Command与Notification之间的映射。当Notification（通知）被

发出时，对应的Command（命令）就会自动地由Controller执行。Command实现复杂的交互，降低View和Model之间的耦合性。

Mediator发送、声明、接收Notification

当用View注册Mediator时，Mediator的listNotifications方法会被调用，以数组形式返回该Mediator对象所关心的所有Notification。

之后，当系统其它角色发出同名的Notification（通知）时，关心这个通知的Mediator都会调用handleNotification方法并将Notification以参数传递到方法。

Proxy发送，但不接收Notification

在很多场合下Proxy需要发送Notification（通知），比如：Proxy从远程服务接收到数据时，发送Notification告诉系统；或当Proxy的数据被更新时，发送Notification告诉系统。

如果让Proxy也侦听Notification（通知）会导致它和View（视图）层、Controller（控制）层的耦合度太高。

View和Controller必须监听Proxy发送的Notification，因为它们的职责是通过可视化的界面使用户能与Proxy持有的数据交互。

不过对View层和Controller层的改变不应该影响到Model层。

初始化

首先Facade是一个单例。在它的构造函数里除了单例应有的部分外，还有一句initializeFacade() 具体的实现是

protected function initializeFacade( ):void {

initializeModel();

initializeController();

initializeView();

}

很明显，这里揭示了Facade主要干3件事情，初始化Model，Controller，View，而这三个都是单例

Model用于保存所有的Proxy，View用于保存所有的Mediator还可以注册一些对notification的监听，而Controller主要是保持一些Command。这些类提供了注册的方法也提供了查询的方法。那么Facade这个类本身也提供了对于Proxy，Mediator，Controller的访问接口。这正符合Facade的本意：将众多的对外接口统一起来，但是也不屏蔽底层的接口。

然后例子中的程序复写了其中一个initializeContrller（）的方法

override protected function initializeController():void

{

super.initializeController();

registerCommand( ApplicationConstants.NOTE_STARTUP,StartupCommand);

registerCommand( ApplicationConstants.NOTE_LOGIN, LoginCommand);

}

建立了两对notification和Command之间的映射关系。

运行时候

最后是一个startup方法来作为整个程序的开始，发出一个表示开始的notification，这个notification则触发了StartupCommand，这是一个多条Command的执行序列。分别是Model和View的准备command，它们完成了LoginProxy的注册，LoginMediator的注册并且把LoginPanel显式在舞台上等待用户输入

我发帖的经验不多，只是按照自己的思路写了些东西，如果大家有不明白的地方我再细细解答。最近大概还准备结合这个例子，对其中用到的几个设计模式进行论述，欢迎高手来讨论。

优缺点

优点

1，支持多语言

Language　Targets

ActionScript 2　Flex 1.5, Flash 8, FlashLite

ActionScript 3　Flex 2, 3, Flash 9/CS3, AIR.

C#　.NET 1.0/2.0 Silverlight, Windows Mobile and Pocket PC.

ColdFusion　ColdFusion 8

haXe　JavaScript, Flash 8, Flash 9 and the Neko VM.

Java　Java Mobile, Standard and Enterprise Editions (ME, SE, EE), JavaFX, Servlets, Applets, and GWT

JavaScript　Browser neutral

Objective C　Apple iPhone and Mac

PHP　PHP 5

Python　Python 2.5 for wxPython, Google App Engine, Pyjamas [13]

Ruby　

C++　MSVC 8.0/9.0/10.0, MinGW 3.4.5, GNU G++, Embarcadero C++ 6.212，支持标准和多核，标准版提供代码分离的方法，多核版支持模块化

缺点

1，灵活度过高，要清晰控制一个事务过程不容易。 这个是由通知无向性决定的，很难确定谁来监听某一个通知，通知不利于调试。

2，代码冗余比较大，Mediator、Proxy等继承类的冗余代码，但是ActionScript不支持Generics以及Reflection能力弱，使得难以消减代码。