Unity之经典优秀框架PureMVC解析(下)-框架补充篇

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


本篇主要是在前两篇基础上的补充说明,概述笔者在这个示例中为什么会这样设计,如何取舍。
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 之 项目中如何坑害你的同事这个应该比较适合你,真心的~~~

发表评论