PureMVC学习系列-从源码深度剖析PureMVC(核心组件工作流程及原理)

        上午通过PureMVC的初始化，了解到了PureMVC部分核心组件的结构，总体来说，通过重载基类Facade的的构造方法，完成Controller,View,Model的初始化，同时明白各组件中的关系及结构，如下所示：

        1.Facade作为整个系统的门面完成各个组件间的复杂关系的协调与组建，所以一个Facade中包含了对Contrller,View,Model以及Command的映射。

        2.Model将缓存多个Proxy的引用

        3.Controller会缓存Command与自定义通知的映射关系，以及对View组件的引用。

        4.View会缓存多个Mediator和多个Obserser（观察者）。

       

          详情参考上一篇：PureMVC学习系列-从源码深度剖析PureMVC(核心组件初始化)

 

          上午剖析的是关键组件的关系和结构，接下来将是工作时，各个组件的工作流程和原理，参考下图：

1.首先触发一个事件，可以是窗体或者原始视图层的基本事件。

 

2.视图向Mediator发送消息，Mediator继承自Notifier 类，属于消息发布者，所以Mediator将拥有自己的监听器，Mediator是PureMVC工作流的第一站，Mediator组件将与View组件与原始视图层衔接到一起，其实Media的出现在整个框架中可以包装原始视图，提高PureMVC对于不同语言环境的兼容性，通常Mediator拥有以下的作用：

1. 1.  转化 View Component 类型 
   2. 监听并响应 View Component
   3. 在 Mediator 里处理 Notification，即与本消息相关的视图更改的逻辑由Media来处理。

3.View组件会向监听消息B的监听者广播消息，其实，消息监听者（Observer）完全可以只监听Mediator就可以完成工作，所以View的出现最大的作用是降低Mediator和Controller之间的耦合度。在注册/取消观察者时不会对Mediator产生影响，让Mediator更加关注自己的工作，更好完成视图变化的工作，这也是软件架构中“高内聚，低耦合”的一个体现。

 

4.在上午的文章知道，Contrller会将自身，和自身方法(executeCommand)实例化成一个观察者（Observer）向View注册，所以收到View的通知后，Controller的executeCommand方法便会执行，会通过commandMap取得关注此消息Command，执行Command的方法，需要注意到是，Command类是无状态的，所以他再真正调用的时候才会被实例化，也就是Controller的executeCommand方法里。Contrller负责衔接视图层与逻辑层，也就是View和Command,再次降低耦合度

 

5.command在执行时，会取出相关的Proxy来，Proxy来完成对消息的处理，如果对处理结果需要处理，就会将处理结果以消息的方式再次发送给Mediator，开始新一轮的事件处理流程，Proxy是由Model管理，Model负责降低Proxy与Command的耦合度。

 

 

以上为跟踪调试发现的PureMVC的工作流程，到目前为止已经清楚了Pure的静态结构，和动态的工作流程，看起来静态动态都有了，貌似差不多了，但是这仅仅算是真正的认识了PureMVC，用一句时髦的话说，现在了解的仅仅是皮毛，如果要真正用活一个框架，认识是远远不够的，需要的时了解，深深的了解，比如完全发现他得优点和缺点，这里说的发现，不是靠别人的几句话，就可以确定，相比更需要的是时间，磨合，经验~