前两篇
MVC在游戏前端的应用，第二篇之设计模式篇
MVC在游戏前端的应用，第一篇之问题篇
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法
一、 先说结论，笔者认为的比较好的MVC的结构。
- model。
-
曾在一本书上面看到一句话，“程序就是数据+算法”，深以为然，所以model就应该是mvc里面最独立的存在。
-
笔者认为，model就是一个数据容器，按模块划分，可以设计成一个单例，便于全局调用。
-
model包含了各种数据结构的dto，dto保存的是服务器的数据，或者本地的数据也可以。dto不仅是数据各种字段的保存，还包含一些对应的数据处理逻辑的函数。
-
如果你的项目没有实现标准的观察者模式，而是使用事件模式，那么dto会依赖某些公共模块，通常是事件管理器，红点管理器，如下。
-
在dto数据变化的时候，需要通过发送事件的方式(观察者模式)，通知界面的刷新和驱动某些逻辑的进行。这使得dto依赖事件管理器。
-
红点的变化跟数据息息相关，所以dto一般也会依赖红点管理器。
-
-
由于dto大多数来自于服务器，所以可以考虑把协议的接收和发送逻辑，写在model里面。如果这样设计，model也会依赖于网络模块。但也可以每个模块单独写一层proto(或者放到controller里面？)，用于协议的接受和发送。model是否依赖网络模块，取决于是否设计单独的proto。
图1. model是dto的容器
- controller与view。
-
controller的划分，有别于一般项目按模块划分，笔者认为应该按预制体划分，也就是一个预制体对应一个controller，但一个预制体可以写多个view来控制(对于复杂的界面，可以写多个view进行控制)。
-
view有很多刷新的逻辑，通常刷新的函数职责也应该是单一的，但是view一般不会自己调用这些函数，而只是对外提供。controller作为高层模块，负责创建这些view，并在适当的时候按需调用view的这些刷新逻辑的函数。
-
如果某个界面数据来自多个model的dto，那么数据处理的逻辑也应该放在controller里面。
-
由于业务需求多变，所以controller应该是修改最多的地方。
图2. controller与view按预制体划分
二、 讨论
-
model(略)。
-
一般项目按模块划分，controller会变得越来越笨重。有的时候，你会发现，把这个笨重的controller分为2个，也会使得controller变得更加轻巧。同时，按模块划分的controller，也违反“类的职责要单一”的原则。
-
view只负责提供对外的界面逻辑接口，但不会自己调用。因为这些逻辑属于业务逻辑，可能是多变的，所以应该放到controller里面，controller是view的高层模块。如此设计，controller可以非常方便实现策略模式。如果view调用自己的刷新逻辑的话，那么在实现策略模式的时候，每个策略可能要同时包括view和controller。
-
controller的数量确实变多了，但是笔者认为结构变得更清晰。就算是按预制体区分，controller的代码量也不会太少，除了一般项目controller的职责之外，controller还负责调用view的刷新逻辑，以满足业务需求。controller还负责监听view的各种控件事件，监听函数也会写在这里。
三、 设计模式
-
单例模式。注意细节，单例类的构造函数应该是私有的。
-
观察者模式。mvc必须要实现一种观察者模式。
-
策略模式。controller作为view的策略。
-
组合模式。界面之间，可以实现一种组合模式。对于有分页的界面，如果你的项目，能够不区分界面的主页和分页，这说明你的项目已经实现了界面的组合模式。
-
中介者模式。如果实现了一个预制体对应(一个controller和几个view)，那么controller也是几个view的中介者，这几个view之间的通讯和交互通过这个controller进行。
四、好处
- 目前我只在一些小游戏里面应用，还需要更多的实践。
最后
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法
-
对于游戏的mvc，似乎没有一种标准的结构，本文只是笔者的一种看法