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擔當橋梁中間層