前言：为了防止累成狗或者变成狗，我们要加倍努力，早日成为大佬咸鱼翻身~~~
本篇主要是在前两篇基础上的补充说明，概述笔者在这个示例中为什么会这样设计，如何取舍。
Unity 之 经典优秀框架 PureMVC （4.1.0版本）解析 （上） 应用篇
Unity 之 经典优秀框架 PureMVC （4.1.0版本） 解析 （中） 框架解析篇
有说的不正确或者不准确的地方欢迎留言指正
大家如果有疑问可以在下方留言，笔者看到会尽快解答，多多见谅~感觉不错可以在文章结尾点个赞，我能赚点积分。
PureMVC 整体结构：
PureMVC框架的目标很明确，即把程序分为低耦合的三层：Model、View和 Controller。
降低模块间的耦合性，各模块如何结合在一起工作对于创建易扩展，易维护的应用 程序是非常重要的。
在PureMVC实现的经典MVC元设计模式中，这三部分由三个单例模式类管理，分 别是Model、View和Controller。三者合称为核心层或核心角色。
PureMVC中还有另外一个单例模式类——Façade，Façade提供了与核心层通信 的唯一接口，以简化开发复杂度。
ApplicationFacade：
Façade类应被当成抽象类, 永远不被直接实例化。针对具体的应用程序，你应该具体编写Façade的子类，添加或重写Façade的方法来实现具体的应用。
按照惯例，这个类命名为“ApplicationFacade”（当然，命名随你喜欢），如前所述，它主要负责访问和通知Command，Mediator和Proxy。
所以笔者编写ApplicationFacade类，并继承成Facade。且创建的ApplicationFacade类也被用来简化“启动”的过程。这种简化启动的过程在示例中体现在如下几点
- 在初次调用
ApplicationFacade Instance时会自动实例化
public static ApplicationFacade Instance
{
get
{
if (instance == null)
{
instance = GetInstance(() => new ApplicationFacade());
}
return instance as ApplicationFacade;
}
}
Facade构造函数中会进行 Model Controller View 的初始化
public Facade()
{
if (instance != null) throw new Exception(Singleton_MSG);
instance = this;
InitializeFacade();
}
/// <summary>
/// 初始化Facade类
/// </summary>
protected virtual void InitializeFacade()
{
InitializeModel();
InitializeController();
InitializeView();
}
- 在ApplacationFacade中重写部分初始化函数（InitializeController、InitializeModel），并调用父类相关函数
protected override void InitializeController()
{
base.InitializeController();
RegisterCommand(Notification.StartUp, () => new StartupCommand());
RegisterCommand(Notification.GameStart, () => new GameStartCommand());
}
protected override void InitializeModel()
{
base.InitializeModel();
RegisterProxy(new GlobalDataProxy(GlobalDataProxy.NAME,new GlobalData()));
}
最后应用程序调用ApplicationFacade类的
StartUpHandle方法，使得应用程序不需要过多了解PureMVC。至此，整个PureMVC框架就已经初始化完成
注意：除了顶层的Application，其他视图组件都不用（不应该）和Façade交互。
MonoBehaviour和Mediator在逻辑上的划分
在Panel类中的职责如下
- 初始化对应的UI组件（InitPanel）
- 初始化UI上需要表现的数据
- 注册注销对应的Component、Mediator、Commond
- 控制UI的相关操作，例如开、关对应的Panel
初始化UI上需要表现的数据放到Panel类中是因为会频繁且大量的调用对应的UI组件。
如果放到对应的Mediator中虽然可以让业务逻辑和UI很好的分离，但是在编写上会提高很多的代码量，且阅读也上也不方便，势必会造成GetHomePanel.xxxx这种大量调用UI 的方式出现,所以笔者认为把这部分逻辑放到Panel中更为合适。
注册注销对应的Component、Mediator、Commond：这些方法放到Panel中是为了让这些生命周期跟随GameObject的创建而创建，销毁而销毁。避免因生命周期与表现的GameObject不符而造成遗漏注销等问题。
控制UI的相关操作：在Panel中仅仅含有纯粹的视图UI的操作，而非业务逻辑操作。也就是说，显示、关闭这些操作都在Panel中，但是什么时候显示、关闭，在显示、关闭时又触发其他操作的这种业务逻辑在Mediator中。
在Mediator类中的职责如下：
- 对Panel中的事件进行注册
- 对UI视图操作的业务逻辑
对Panel中的事件进行注册：进一步的让Mediator与UI层的解耦，也让代码阅读更清晰。
对UI视图操作的业务逻辑： 提高阅读性，更好的封装。这也是MVC三层的精髓所在。
视图和控制它的逻辑分离开来。
如果一个Mediator要和其他Mediator通信，发送一个或多个Notification，通知别的Mediatora或Command作出响应（甚至有可能发送给自身），而不是直接引用这个Mediator来操作。让一个Mediator直接去获取调用其他的Mediator，在Mediator中定义这样的操作本身就是错误的。迪米特法则（Law Of Demeter）
Mediator对外不应该公布操作View Component的函数。而是自己接收Notification做出响应来实现。
如果在Mediator里有很多对View Component的操作（例如：InitDataAndSetComponentState函数），那么应该考虑将这些操作封装为View Component的一个方法，提高可重用性。
如果一个Mediator有太多的对Proxy及其数据的操作，那么，应该把这些代码重构在Command内，简化Mediator，把业务逻辑（Business Logic）移放到Command上，这样Command可以被View的其他部分重用，还会实现View和Model之间的松耦合提高扩展性。
Command类是无状态的，只在需要时才被创建。
通过订阅对应的Button事件，进一步的降低ViewComponent和Mediator的耦合度
Mediator监听的消息在5条左右，大于5条可以考虑多个Mediator(笔者实际开发中一般10条以内都会在一个Mediator中，毕竟开发时间有限)
如果一个Mediator需要和其他的Mediator进行大量的交互，那么一个好方法是利用Command把交互步骤定义在一个地方。不应该让处理Notification的方法负责复杂逻辑。业务逻辑应该放在Command中而非在Mediator中
Proxy
对数据的操作放在Proxy中，计算完后发送消息，执行相应的结果。也就是说，在Proxy的逻辑仅仅是对数据的操作，并没有控制UI先关的业务逻辑。
以上就是笔者对PureMVC的理解，不知道能否帮助到此刻正在看博客的你~
在实际开发中虽然不一定要墨守成规，毕竟MVC是一种思想，但还是能尽量遵守就遵守这些规则。基础打好，其他的同事也方便阅读或者更改。也会因为良好的编码风格让大家都能有一种规范编码的默契。
前人栽树后人乘凉。前人挖坑后人掉坑。
但如果遇到一个这个功能很简单，修修改改就可以，或者怎么实现我不管，明天我就要的管理，兄dei请参考我的另一篇博客：Unity 之 项目中如何坑害你的同事，这个应该比较适合你，真心的~~~
