主要是mvc架構，
M層爲數據層，兩個用途：1保存數據；2發送數據更新信息；
V層爲視圖層，兩個用途：1接受用戶從界面上的操作；2根據M層的數據顯示相應的界面；
C層爲控制層，兩個用途：1處理和界面無關的代碼邏輯；2接受和處理網絡數據；
繼續……
按照自己的經驗，遊戲中的mvc架構有兩種思想，1，以mvc架構爲主，整個框架就是一個mvc架構；2，以對象思想爲主，對象中使用mvc架構，整個框架使用一個平行結構。先看看使用mvc架構的方式，如下圖：
各個模塊分爲mvc三部分，有些模塊可能只有其中一部分，比如只有view，只有model等。不同模塊的mvc三部分對於其他模塊也是可見的，比如bagview可以訪問rolectrl，也許不需要訪問，這裏只是舉例說明，rolectrl對於bagview是可見的。
整個框架的運行流程如下：
A 玩家在界面上操作的情況：
1 玩家的輸入在view層處理，比如玩家在包裹面板上使用了一個道具，此道具的作用是給玩家一個buf，操作由bagview處理；
2 bagview將使用道具的操作轉換爲和界面無關的操作，發送給bagctrl，比如將界面上該道具的位置轉換爲包裹中的索引位置；
3 bagctrl在收到請求後將操作組裝成請求包，通過networkIO發送給服務器；
此時，操作的前半部分就已經結束，操作帶來的影響需要服務器處理
4 服務器返回操作結果，比如此時返回了兩個協議，通過NetworkIO中對包的協議分析，分別發送給bagctrl處理和rolectrl處理；
5 bagctrl根據包的內容，此處應該是包裹中扣除一個道具，調用bagmodel的方法，扣除指定的道具；
6 bagmodel將數據更新，併發送包裹更新的事件到事件管理器；
7 事件管理器將包裹更新事件廣播出來；
8 bagview註冊了包裹更新事件的監聽，bagview在收到事件後判斷是否需要更新界面顯示，如果需要，則獲取bagmodel的數據，根據數據更新界面；
包裹的處理就已經完成了
9 rolectrl根據包的內容，此處應該是玩家擁有了一個新的buf，調用rolemodel的方法，增加buf；
10 rolemodel將數據更新，併發送玩家信息更新的事件到事件管理器；
11 事件管理器將玩家信息更新事件廣播出來；
12 roleview和headview都註冊了玩家信息更新事件的監聽，
13 roleview根據當前玩家狀態決定是否需要更新玩家3d形象，如果需要，則獲取rolemodel的數據，做相應更新，比如在頭頂加一個特效等；
14 headview根據當前玩家狀態決定是否需要更新玩家頭像信息，如果需要，則獲取rolemodel的數據，做相應更新，比如在面板上加一個buf的圖標等；
B 處理網絡包的情況，其實就是上面流程中從步驟4開始到最後。
整個流程中需要注意幾點：
1 在接受玩家的操作之後，如果沒有特殊需求，view不能直接更改顯示，顯示的更改都要根據model發出的事件來觸發；否則，在多個條件影響同一個view時，會出現錯誤；
2 view不能直接修改model的數據，只能讀取，model的修改只能由ctrl來做；否則整個框架在遊戲規模變大之後會變得相當混亂；
3model的作用只能是修改自身數據，並且發送事情出來，不能有其他操作；
由於完全開發各個模塊各個層之間的可見關係，會將整個框架變爲一個很複雜的網狀結構，給拆分和擴展帶來很大的麻煩，所以在可見性上做以下限制：
1 model層不能調用任何其他模塊方法，只能調用事件管理器方法發送事件；
2 control層只能調用自己模塊的model層方法；也就是說control層不能修改其他模塊model層的數據；如果一個control必須要更改另外一個model的數據，可以通過調用另外一個control的方法來間接修改；
3 control層之間可以相互調用；因爲處理網絡IO的包時不管怎麼樣都需要在一個地方處理各個模塊之間的交互，所以可以放在control層；
4 view可以調用其他模塊的control層，但是不能view調用其他view，如果出現這種情況，一般都是設計不當造成的；
整個框架的調用關係就如下所示：
先寫到這裏……