pureMVC与设计模式之一. 结构与工作流
引言
设计模式是软件开发人员的九阳神功。设计模式有基本的23种，九阳神功有九层。学习设计模式容易看似会了生搬硬套，修炼九阳神功容易根基不稳走火入魔。但是，如果最后都深刻理解，融入贯通的话，无疑已是基本天下无敌，见招拆招，随机应变。整个修炼过程是曲折的，需要不断的实践，理解，反思，升华。
MVC，非常著名的软件构架，将视图（表现层），控制流，模型（数据层）分开， 在web开发，UI设计等有很多应用，里面用到了23中设计模式中很多具体的模式。MVC有很多种实现，其中之一是开源工程puremvc，这是一个多语言实现的MVC的framework，简单纯粹，一如他的名字。通过分析MVC来加深对设计模式的理解，无疑是一个学习的好办法。下面几个部分组成：
- pureMVC与设计模式之一. 结构与工作流
- pureMVC与设计模式之二. Facade模式与Singleton模式
- pureMVC与设计模式之三. Observer模式
- pureMVC与设计模式之四.Mediator模式
- pureMVC与设计模式之五. Command模式
- pureMVC与设计模式之六. Proxy模式
- pureMVC与设计模式之七. 扩展与简洁的权衡（名字还没想好，待定）
作为开头，本为先从宏观上介绍pureMVC的，以及工作流的过程，最后用例子来说明如何应用。
pureMVC结构宏观
图1. pureMVC结构图
从中可以看出整个pureMVC中有三个最主要的部分：Controller, View, Model，分别对应MVC的三个要素，分别由一个单例类来实现，是整个框架的核心层。除此之外，引入另外一个单例Facade，其中包含有M、V、C的引用，所有的pureMVC操作都是通过Facade来进行，不用去管是该用到底是用V，M，还是C。他是为了使用pureMVC方便而专门设计的一个工具类，
除了四个大圆，还有几个小圆，和方块。各种小圆依然是pureMVC的组成部分，而方块就属于应用程序自己的部分了，是pureMVC操作的各种，如数据，UI等。小圆的出现是为了方便的将各种资源引入pureMVC供其使用，同时保持很强的扩展性，这些在后面的proxy模式，observer模式，mediator模式等具体分析。
大家一定注意到有一种小圆，他们没有跟任何方块进行交互（没有直接的箭头），没错，是command。他们代表的是另外一种资源，控制流。控制流是整个程序运行和核心，业务流程的实现是不同模块之间发送事件（Notification）来进行控制和交换信息。例如如果想更新界面中某个 Mediator，首先我们定义 Notification 用于此目的，然后注册 Mediator 监听该Notification，然后就可以在程序中任何地方生成一个 Notification，通过事件机制，Mediator 就会接收到 Notification，然后更新需要的部分。整个过程 Mediator 只和 Notification 有关，没有其他依赖，有效的降低了对象之间的依赖程度。
pureMVC中的控制流
图2是pureMVC初始化的流程图。从图中可以看到，调用Facade的初始化方法即可以同时初始化好Controller, Model以及View三个组件。初始化好后，便可以注册Mediator, Proxy和Command。值得注意的是，注册Command和Mediator，都会在View中注册对应的Observer。这里的Observer即是观察者模式的一种实现，每一个Observer都有一个感兴趣的事件。当事件发生时（调用facade.sendNotification），Facade会把事件传给view，而view则会调用所有已注册的对该事件感兴趣的observer的方法。
举个例子，如下图3所示。当UI进行改变的时候，会通过Mediator调用Facade发送一个Notification事件。Facade则会把此事件传给View，然后View会找出对这个事件感兴趣的所有的Observer，调用Observer的notifyObserver方法，有每个Observer去处理对事件的响应。在以后的文章中会通过源码分析，加深对这些各种模式应用的理解。
图3. Mediator引发的事件处理
本文就介绍到这里，pureMVC的具体使用，网上有很多简单应用的代码实例，这里就不再赘述。在以后的文章中，会逐个分析pureMVC中的设计到的各个设计模式。