前言:为了防止累成狗或者变成狗,我们要加倍努力,早日成为大佬咸鱼翻身~~~
本篇主要是在前两篇基础上的补充说明,概述笔者在这个示例中为什么会这样设计,如何取舍。
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 之 项目中如何坑害你的同事,这个应该比较适合你,真心的~~~