Unity 之 经典优秀框架 PureMVC （4.1.0版本） 解析 （下） 补充篇

前言：为了防止累成狗或者变成狗，我们要加倍努力，早日成为大佬咸鱼翻身~~~

---

本篇主要是在前两篇基础上的补充说明，概述笔者在这个示例中为什么会这样设计，如何取舍。

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 之 项目中如何坑害你的同事，这个应该比较适合你，真心的~~~