Unity3d——UI框架的设计 (转)
转自：
https://blog.csdn.net/zzwdkxx/article/details/82014926
简易UI框架
1.UI框架核心方法
- BaseUI会记录UI的名字（枚举）和Controller用来将UI与具体操作方法解耦
- UIManger利用字典记录所有的UI组件，然后提供一些打开关闭UI的方法
- EventManager(事件系统)来实现模块与模块之间的交互,事件系统也分很多种实现方式,都是观察者设计模型的典型应用,利用一个关键字注册多个方法，然后在利用这个关键字激活调用已经住的方法。也是C#中委托的一种典型用法。广播形式、通知形式等。
2.UI框架拓展方法
- ResourcesManager（资源管理器）,封装一些加载Resources资源的方法，同步加载，异步加载,加载并实例化等方式的方法。
- DataHelper(数据解析器),对Xml、Json(LitJson、JsonFX)、Protobuf等数据格式序列化与反序列化插件的进一步封装，方便调用。
- Common Extension（公共拓展组件）利用泛型和拓展方法对Unity中的方法进行进一步的封装，加快开发速度。
- Singleton(单例)
- NetworkManager,负责与后台数据的下载、上传。
3.简易UI框架的优缺点
- 容易上手使用
- 针对C#新手相对容易理解
- 只适合很小的项目
- 拓展性很差
- 逻辑会堆在MonoBehaviour的脚本下,效率降低
躺过上面这种简易UI框架的坑之后，才会意识到一个大一点的项目，或者是多人合作开发的项目，一定要有一个较为牢靠的框架做为基础，在Unity中有几种常见的框架，也是从传统的经典矿建拓展过来的。PureMVC（MVC框架）,StrangeIOC（MVCS框架）,uFrame(MVVM框架)。
为了对比这三种常用框架的易上手程度和开发速度、理解难度，我将用同一个案例，用三种框架都编写一次，实实在在的对比一下框架的区别之处，得出最终的结果。
PureMVC框架:
PureMVC优缺点：
- 1.利用中介者，代理者，命令实现解耦，使得Model、View、Controller之间耦合性降低,提升了部分代码的重用
- 2.View界面可以实现重用
- 3.Model数据可以实现重用
- 3.代码冗余量大,对于简单的功能都得创建View、Mediator、Command、Facade，Proxy，Model脚本
- 4.操作过程比较繁琐的流程，Mediator中的代码会显得流程较为复杂难懂，除非你很熟悉PureMVC执行原理
PureMVC特点：
- 1.通知的传递都要经过装箱和拆箱的操作
- 2.命令/通知是以观察者模式实现，命令/通知在观察者中利用反射获取方法并执行
- 3.没有Service（可按照MVC的构造，自行添加与网络通讯的这个模块）
- 4.数据通过通知传递，SendNotification只有一个object类型参数，会感觉数据传输受限，可以将数据组合成一个类型/结构传递，或者是为Notification再拓展一个参数。
PureMVC Core Scripts // 核心文件
1.View.cs : IView.cs
- 1.字典记录已注册的中介者(key是中介者名字，value是中介者接口)
- 2.字典记录已注册的观察者(key是事件名称,value是观察者接口)
- 3.提供注册/注销中介者和观察者的方法
- 4.核心方法通知观察者的方法NotifyObervers
- 5.实现View单例
- IView.cs接口规了View要实现的方法
2.Controller.cs : IController.cs
- 字典记录已注册的命令(key是命令的名称,value是继承命令类型(实现命令接口)的类型)
- 记录IView接口,以此来执行View中的通知,IView在构造Controller时赋值的
- 实现Controller单例
- 提供注册、注销、执行命令的接口
- IController.cs接口规了View要实现的方法
3.Model.cs ：IModel.cs
- 字典记录已注册的Model代理(Proxy)(key是代理名称,value是代理类型接口)
- 实现IModel的方法，包括注册、注销、获取代理的方法
- 实现Model单例
- IModel.cs接口规了View要实现的方法
在了解了核心代码的字段和方法之后，我们应该对PureMVC框架有个大概的了解，MVC三个脚本分别记录管理项目创建的所有的视图，控制器和数据模块,然后PureMVC框架利用几种典型的设计模式解除了三个模块之间的耦合，使得View和Model的代码重用性提高,下面我们简单的讲解一下涉及到的设计模式。在这里推荐一本书《大话设计模式》,不了解的同学可以去学习一下。
设计模式
- 代理模式
为其他对象提供一种代理以控制对这个对象的访问。
使用：在PureMVC中的使用代理模式在PureMVC中隔离了数据与其他系统的直接交互，都通过数据的代理类来进行操作，因为代理类又是继承至Notifier的所以Proxy也可以通过Notifier.IFacade访问到View和Controller，有效的隔离了数据类与其他类的耦合，使得数据类的复用性提升。这样数据类中的数据也可以由策划来用工具生成，使得开发更加的方便。
- 外观模式
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个模式使得子系统更加容易使用，完美体现依赖倒置原则和迪米特法则。使用外观模式可使子系统之间的依赖降低。
可以为旧的子系统设立一个Facade类，然后用Facade类去与新的系统交互，降低旧系统对新系统的依赖和产生复杂的关系
使用：在PureMVC中利用外观模式编写的Facade类是整个MVC框架对外的主要接口，在Facade类中记录了View、Model、COntroller并且实现了单例,它几乎拥有MVC核心类中的所有对外接口，是一个典型的高层接口。
- 观察者模式
是一种一对多的依赖关系，让多个观察者对象同事监听一个主题对象，这个主题对象发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
使用：在PureMVC框架中利用观察者模式，在中介者类的构造函数中给中介者注册对应UI事件之后，当UI触发事件时，中介者会通过View再把通知下发给观察者，View中记录了每一个事件对应的观察者的字典，对观察者进行遍历然后执行通知中的具体事件，这里在事件通知时将类型装箱为object类型，在观察者中又通过拆箱为具体类型，利用反射构造方法实例执行，来执行通知的事件，通知的事件在构造中介者时，通过重写ListNotificationInterresets方法实现添加。
PureMVC中命令模式实现也是通过发送通知，让观察者执行通知调用Controller中的ExecuteCommand来触发的命令。
- 中介者模式
用一个中介对象来封装一系列的对象交互。中介者使各个对象之间不需要显示的互相引用，从而使其耦合松散，而且可以独立的改变它们之间的交互。
中介者的优缺点都很明显：优点是它减少了各个具体的类之间的耦合，使得可以独立地改变和复用各个类型。缺点是：中介者的控制会随着逻辑复杂而更加复杂，这会使得中介者承担过多的任务。使用：在PureMVC框架中利用中介者模式有效的隔离了View层与Controller和Model层的耦合，View通过持有的数据代理，就可以有效的执行操作和数据处理。
- 命令模式
将一个请求封装为一个对象(即我们创建的Command对象），从而使你可用不同的请求对客户进行参数化; 对请求排队或记录请求日志，以及支持可撤销的操作。
抽象命令（Command）：定义命令的接口，声明执行的方法。具体命令（ConcreteCommand）：具体命令，实现要执行的方法，它通常是“虚”的实现；通常会有接收者，并调用接收者的功能来完成命令要执行的操作。
接收者（Receiver）：真正执行命令的对象。任何类都可能成为一个接收者，只要能实现命令要求实现的相应功能。
调用者（Invoker）：要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
客户端（Client）：命令由客户端来创建，并设置命令的接收者。
使用： SimpleCommand和MarcoCommand继承ICommand接口,实现Execute方法。在代码中调用SendNotification(命令的名字)，然后通知会在View.NotifyObserver()方法中通知观察者，观察者通过反射获取方法，然后执行Controller中的ExecuteCommand，ExecuteCommand中又会从字典中获取命令对应的类型，然后调用Execute执行重写的命令，实现解耦。
- 单例模式
单例模式是最常用的一种设计模式，单例见名知意就是一个类只有一个实例。
单例模式提供一个全局的访问点，是的程序的开发变得更加的灵活，但是单例类的增多也会导致代码过度耦合，降低复用与维护。使用：在PureMVC中，Facade、View、Model、Controller都实现了单例模式，使得批次访问更加的方便，并加以volatile关键词（volatile多用于多线程的环境，当一个变量定义为volatile时，读取这个变量的值时候每次都是从momery里面读取而不是从cache读。这样做是为了保证读取该变量的信息都是最新的，而无论其他线程如何更新这个变量），提供互相调用的接口。
