pureMVC 学习笔记

pureMVC 框架实现了经典的MVC设计模式，框架的目标是把应用程序分为低耦合的三块：Model，View，Controller。三者协同工作，创建易维护、易拓展的程序。

 

要点：

　　1.Facade 外观模式。外观模式要求外部系统与其子系统通信必须通过facade提供的统一接口，如同客服一样，你需要查询订单，你只要跟他说即可，他去访问内部系统再给你结果，免去你与内部系统交互，从而更方便。facade封装了Model，View，Controller，使得你只要通过facade提供的接口就可以访问三大核心层模块，三大核心层模块也通过facade来交互。更加简化了程序，方便调用。　　　　

 　　　　http://www.cnblogs.com/wzh206/archive/2010/03/21/1691112.html

　　2.Model 与 Proxy. Model 保存了所有的Proxy对象引用（map），并通过retrieveProxy(ProxyName)来获取，Proxy负责操作 数据模型，与远程服务通信存取数据。

　　　　Model 在必要的时候（比如数据更新）想系统发送消息（Notification）,并且只管发送，不管谁接收，也不管怎么处理。

　　　　Model不监听系统的Notification，因为这样使得耦合性加大。它可以提供必要的接口给Mediator或者Command调用。

　　3.View与Mediator。View保存了Mediator对象的引用，通过retrieveMediator(mediatorName)来获取。Mediator负责管理和操作视图组件，以及作为组件与系统交互的中介。

　　　　Mediator给component添加事件，接收\发送Notification，直接改变component状态等。

　　　　重写 listNotificationInterests返回自己感兴趣的消息以及handleNotification处理对应的事件。说是不推荐这种做法而是通过注册Command去在Command中处理。两种搭配吧

　　　　Mediator也可以开放一些借口在Command中被调用。记住！！不能再Mediator中直接引用Mediator。 也不推荐在Mediator中引用Proxy对象，这种应该放到Command中处理

　　　　Mediator中的handleNotification 处理的分支一般低于四五条，多了的话就拆分开。

　　　　它与ui的交互通过自定义事件实现，例如用户单击按钮，广播一个事件(此事件不是Notification),在Mediator中监听到后再sendNotification到系统

　　4.Controller 和Command。 Controller保存了Command对象的引用。Command有两种：macrocommand和simpleCommand。

　　　　macrocommand一般用于初始化系统时，只要重写它的initializeMacroCommand函数即可，在函数中调用addSubCommand(class),添加多个待执行的命令，通过FIFO的方式执行

　　　　simplecommand重写 execute函数即可。一般复杂的逻辑处理都放在这里。可以在此处获取Mediator或者Proxy的引用，继而调用对应的接口。

　　　　Command是无状态的，当一个Notification被发出去时，Controller会对Notification分析，找到对应（原来注册的Command与NotificationName映射）Command并实例化，调用execute

 

 

 

“我经常用于比喻MVC的例子是小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。Model则是游戏卡带，他绝定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。” ----引至网络