PureMVC新手入门

PureMVC是一个Unity常用的入门简单框架，PureMVC分为标准版本和多核版本。这里只讨论单线程下的PureMVC的学习笔记。

文章目录

1.什么是PureMVC
2.各层的职能
3.PureMVC流水线
4.生命周期
5.模块化协作开发
6.实际开发中会遇到的问题
6.PureMVC内部进一步划分
7.用到的设计模式

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模式是为了简化外围系统与系统三大核心类交互的复杂度。