PureMVC是一个Unity常用的入门简单框架，PureMVC分为标准版本和多核版本。这里只讨论单线程下的PureMVC的学习笔记。
1.什么是PureMVC
MVC全名是Model View Controller,是模型(Model)-视图(View)-控制器(Controller)的缩写，一种软件设计典范，用一种业务逻辑，数据，界面显示分离的方法组织代码。通过把职责，性能相近的成分归结在一起，不相近的进行隔离，MVC将系统分解为模型，视图，控制器三部分，每一部分都相对独立，职责单一，在实现过程中可以专注于自身的核心逻辑。
而PureMVC架构在MVC基础上通过引入Mediator+事件(通知)机制很好的解决了view(视图层)与controller(控制层之间的紧耦合问题)。
在大型项目中，MVC中的Controller主要就是负责协调View与Model,让两者之间尽量“解耦”。(相互之间不知道对方的存在)
PureMVC是一款基于MVC的开源框架，最初是为基于ActionScript3的Flash程序开发的，后来被移植到16种语言平台上。
使用框架的主要目的：
1.项目耦合性低，复用性高。
2.相对于复杂多变的需求变化，一般逻辑编写都相对固定(位置固定，方式固定)，减轻了复杂项目对程序员的“功力”的要求，特别适合中大型项目以及需求变更频繁的情况。
MVC与PureMVC对应关系图
| MVC | PureMVC | |
|---|---|---|
| 模型图 | Model | Proxy |
| 视图层 | View | Mediator |
| 控制层 | Controller | Command |
2.各层的职能
| 名称 | 继承接口 | 职能 |
|---|---|---|
| 模型层 | Proxy | 1.发送但不接收消息。 2.与服务器端连接，获取与上传业务数据。 3.大型网络游戏，可以进一步抽象出“数据代理服务层”,专门从事与服务器交互通信事宜。 |
| 视图层 | Mediator | 1.发送与监听消息. 2监听Component自身的事件，且转化为消息。 3.设置与调用Component数据与方法。4.直接调用Proxy(推荐尽量少用)。 |
| 控制层 | Command | 1.管理Proxy与Mediator层，负责注册，查询获取，移除等。 2.直接调用多个Proxy，进行复杂业务逻辑处理。 3.对(继承MonoBehaviour)的脚本做动态管理与对象加载操作。 4.Command本身生命周期很短，在整个生命周期中并没有类的实例在运行，而是通过反射技术，一次性的得到类的对象(object),执行完(Execute)后结束。 |
3.PureMVC流水线
补充说明:
1.这里箭头表示意思是如果你打断点调试，按F11跟代码框架的流程。
2.这里虚线箭头方向不推荐使用，因为方向太多，在大型项目中容易乱。
3.为什么还会有控制层调用视图层，视图层调用模型层，这个考虑就是不要有太多的命令通知和消息通知，命令消息通知太多会造成项目的混乱。
4.模型层(Proxy)对外不处理消息，只能发送消息。
4.生命周期
PureMVC中三层生命周期不同:
1.Mediator与Model类都是从实例化到项目结束，或者手工销毁。
2.Command控制类，生命周期是从发起一个“命令消息”，PureMVC框架内部按照事先“绑定”的对应Command类，实例化一个对象。然后Command实例执行完Execute()重载方法后，立即销毁。
5.模块化协作开发
PureMVC通过Mediator与消息事件的机制，强有力的对项目进行分层解耦，这特别有利于模块化的开发与多人分工协作。
模块与模块之间只需要注意其消息的交互，而不用理会其里边的实际逻辑，在划分好功能模块后，使得多人合作开发能够更好的执行。
6.实际开发中会遇到的问题
1.把更多的逻辑都放在Mediator里面做处理，则可能会导致Mediator太庞大的问题。
2.Command中消息数量的问题:
命令模式(Command)将逻辑操作分离出来，使程序的耦合性进一步降低。但在实际的使用中可能会导致数量太多的问题。
如果对每一个"操作"(按钮，请求等)都去写一个Command的话，显得太过琐碎，消息名与Command的过量反而难以管理，这个需要在实际项目中结合具体业务逻辑进行取舍与综合考虑。
6.PureMVC内部进一步划分
视图层Mediator分为纯显示类View和显示控制类Mediator。
View:只负责简单的窗体数据显示。
Mediator:负责显示层的通讯，按钮点击事件，数据深度处理(需要多个类，
多个窗体协作)。
模型层Proxy分为纯数据类Vo和模型代理类Proxy。好处是:"数据本身"与"数据操作"相分离，易于存储，扩展等，耦合性降低与扩展性提高。
7.用到的设计模式
1.单例模式:三层与Facade都是单例模式。
2.观察者模式:消息传递。
3.中介者模式:用一个中介对象来封装一系列的对象交互。
整个PureMVC通过框架的约束与规则，对于外部系统(例如Unity脚本)来说，就是起到了一种"中介者"的作用，脚本之间不直接关联与调用，这就是一种架构级别的"Mediator"(中介者)设计模式的体现。
4.外观模式(Facade):为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
5.代理模式(Proxy):为其他对象提供一种代理以控制对这个对象的访问。
6.命令模式(Command):将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。
PureMVC是两种主要的模式贯穿整个框架：
1.委托/事件:微软是开发了一种比较自然的直接实现观察者模式的一种技术。
定义了一种一对多的依赖关系。视图控制层先注册，一旦我们使用SendNotification
,就会执行这个消息，最终使用反射的技术，把我们对应对象里面的对应方法执行了，就是实现了PureMVC中的消息传递，使得耦合性非常低的一种层和层之间的消息传递，这就是我们观察者模式。
2.中介者模式：用一个中介对象来封装一系列的对象交互。
我们把项目分为三层就是为了解耦，层和层之前可以独立的改变。
3.Facade模式是为了简化外围系统与系统三大核心类交互的复杂度。