前言
因为之前都是在一些比较成熟的框架结构里补逻辑，所以也不觉得有什么特别的问题，最近看了一些半成品的代码逻辑之后才真真的意识到框架设计的重要性。这里就说一下我相对熟一些MVC的结构吧。首先先看一下传统MVC模式的介绍。
简介
MVC开始是存在于桌面程序中的，M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
MVC 编程模式
V即View视图是指用户看到并与之交互的界面。比如由html元素组成的网页界面，或者软件的客户端界面。MVC的好处之一在于它能为应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，它只是作为一种输出数据并允许用户操作的方式。
M即model模型是指模型表示业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，模型与数据格式无关，这样一个模型能为多个视图提供数据，由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
C即controller控制器是指控制器接受用户的输入并调用模型和视图去完成用户的需求，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。
关于游戏中MVC的使用理解
参与过很多项目，其中很多宣称使用MVC架构的项目，在使用中就很奇怪，要么M层丢失，要么M层和C层交杂在一起。反而增加了代码量还影响了执行流程导致逻辑繁琐又混乱。
即可能想要用MVC架构, 但实际使用的是V + C的模式，即View层做显示组件的初始化。Ctrl层做页面的逻辑处理，因为没对modle层做管理，需要数据驱动的时候，就把数据存在Ctrl层或其他什么地方，这样不但需要在Ctrl层提供一些的方法返回这些数据给其他地方使用，还需要去找其他对应的数据的位置，如果是子页面层或者孙页面层的数据，那么拿起来就别提多复杂了。
那么对于MVC在游戏中的使用,我觉得其实这里的Model层称为Data层可能更好理解，即Model代表的是一个开放的数据层。所有View层的变化都是数据驱动的。
比如对游戏内对UI页面的控制，简单的示意图如下：
数据模块是公共的，就像是一些全局变量一样，都可以访问到，这样的话，比如一个模块的View受多个模块的数据影响，我们就可以很方便的控制，而且比如我们的三级页面需要显示，但二级页面出现了问题，我们甚至可以直接从对应模块的数据层直接拿到想要的数据来更新三级页面的View。
这样的模式才能很好的应对有些交叉数据，和父子层级数据不通带来的代码逻辑混杂维护困难的问题。
尾记
现在大部分项目开发节奏挺快的，很多人都有功能先做出来再说，后面慢慢改的想法。
这种大部分实际情况就是一直刨坑，实现的功能很难或者根本无法做扩展，后面就是一直花费大量时间和精力填坑，实在填不动了就跳槽，总的来讲虽然没什么毛病吧，但还是对后来人不太友好。而且谁能保证我们跳的不是另一座屎山呢。
所以总的来讲写代码之前还是先整体考虑一下同类游戏的功能点，做个大概的结构规划再开始吧。
而且，游戏架构只是对游戏功能点的关系的处理，并不是我使用了xlua或者et框架等等游戏框架就可以直接开撸了，这些网络框架只是对一些通用功能点的封装而已，和你自己游戏的功能点可没关系。
以上。