Cocos2d-x项目的MVC框架
本篇所用的Cocos2d-x版本为：Cocos2d-x 3.2
当我们已经开始搭建好项目，着手开始写代码的时候，我想同学们肯定会遇到这样的一个问题：
某些UI类在加载到父级上之后，经常毫无原由的造成崩溃现象。或者代码写了好几千行，难以进行维护及其他人帮助处理等。这是为什么呢？
其实，就是因为2点：
-
你对Cocos2d-x还是不够了解
-
你没有框架的概念
其实，这种问题往往是因为，你子级元素在父级addchild之前，就开始调用到了父级元素。或者说你就一直埋头去写，根本没有去想到底该怎么写。
我以前在交流群里经常对遇到这种问题的同学这么说：“你孩子还在母亲肚子里没生出来呢，你让它去打酱油可能吗？”
“你的孩子应该有无限的未来，为什么你不给它好好的去规划未来，而直接就开始给它戴上紧箍咒，让它束手束脚？”
我以前初学Cocos2d-x的时候经常会遇到的一个误区。那就是 在init函数里添加了显示UI或需要父级的数据等。
其实在init里面添加显示UI的代码，并没有问题，但是对于我的编程经历上来讲，这并不好,我个人认为你初始化就应该做初始化的事，你的UI就应该在UI的函数里进行加载，逻辑就应该在逻辑函数内，而不是哪地方都是。
我想了解MVC框架的同学们，都清楚MVC到底是什么了，那么我引用一下度娘对MVC的定义：
MVC 全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面 显示分离的方法组织代码，将业务逻辑*****到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起 来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
在我一开始得知MVC框架的时候，我也纠结了很久，对于小项目来说这种框架非常的消耗时间，往往在一个类里面就可以搞定的东西，非要分成4份，管理器、业务、UI、逻辑。在这里我只能说是仁者见仁，智者见智了。
我先说说这种框架的好处：
1、你可以很轻松的将以前的业务拿到任何的新项目中。
2、你可以在策划变更逻辑、美术改变UI后，不用重新对逻辑和业务做过多的修改。
3、你可以很轻松的找到问题的所在，代码鲜明、整洁、规范。
坏处：就是你会觉得很烦，明明一个非常简单的业务，非要写这么复杂。
那么将MVC框架运用到Cocos2d-x上，是什么样子呢？
首先同学们看一下我写的基类BaseLayer
根据我的个人经验，我赋予了BaseLayer这几个简单的函数：
1、初始化及数据读取
2、显示及加载UI
3、加载逻辑与返回逻辑
……
就像上述，inti()就只是负责初始化，而showUI()就只是负责显示及加载UI，加载与返回逻辑就负责逻辑处理。
那么我们对比MVC架构和BaseLayer来看：
-
模型(model)————BaseLayer数据的初始化及本身业务
-
视图(view)————BaseLayerUI的初始化及加载
-
控制器(controller)————BaseLayer的逻辑处理及返回
那么BaseLayer的实现一般就是这样的步骤：
1、inti();
2、GetReadData();
3、LoadUILogic();
4、showUI();
5、ReturnLogic();
以实际功能业务为例：装备升级功能
我现在有个需求，需要实现对装备的升级功能。
我们以BaseLayer为基类，派生出业务类Equipment_LvUp (请原谅我小学英语毕业)。
|
1
2
3
4
5
|
Equipment_LvUp* m_pEquip = Equipment_LvUp::create();this->addchild(m_pEquip);m_pEquip->GetReadData(…);m_pEquip->LoadUILogic (…);m_pEquip->showUI (); |
从 顺序上，我们不难看出，先初始化数据、然后获取业务必要数据、加载业务逻辑、显示业务视图UI我们这么做之后，如果发生问题可以轻松的去判断问题的所在， 是因为数据、显示、还是逻辑。而后，当我们的业务逻辑变更后，可以根据需求去调整代码，既鲜明，又直观。而且你可以把业务扔在不同的管理器下随时调用，可 谓是相当的方便。
而且我们还可以根据不同的需求，对它进步一再重构及功能提升。像资源的异步加载、业务算法优化等等这些功能就可以逐步的完善。也可以分写4个类，就像之前提到的管理器、业务、UI、逻辑分类写。这些方法用哪个都可以，这只是给你提供一个思想、一个方式而已。
MVC 框架我的理解，通俗点讲，就好比你玩英雄联盟，你的事件是通过鼠标及键盘进行响应的，也可以说是你的直观逻辑处理，QWER每次点击都会通过键盘映射到相 应的逻辑进行处理，逻辑处理完之后通知相关UI进行动画或者渲染等，然后UI再给你提供新的界面，以供你进行新的选择。
那么从Cocos2d-x的demo也不难看出这种框架模式
逻辑分离
根据逻辑引用计数的增加和减少采用不同的类进行处理
每个类只负责自身的显示及动画效果。
-
晕死，mvc又不会是万能工 具，model->view->controller这种结构适合事件驱动或者纯数据驱动的东西，网站、应用app都可以，游戏本身是 main loop的结构啊亲，跟mvc压根是两个设计思路，你非要去为了套用mvc的思维去强行把这个加上去，除了多此一举之外，会导致很多游戏设计的实现变得异 常繁琐－－－在应用开发中，有些繁琐是必要的，因为一个应用需要从小到大很多年的不断改进；但是游戏不同，游戏生命周期就一两年，之后就是维护，所以游戏 的架构是效率第一，方便修改第一。支持(9)回复(2)
-
mvc有个缺点是m，v不是分开的，v可以访问到m，但是m不能访问到v，所以就弱化了c的作用，所以我更趋向于mvp这个模式，数据传输模型 m->p->v 用户输入模型 v->p->m 这样就能把m、v解耦，p担当桥梁中间层