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层。