话说在前头，我分析MVC模式是为了确定自己要做的独立游戏的结构出来，并不适用于大型商业游戏的开发。
MVC模式的概述
关于MVC模式，Model用于存储数据，View层用于显示数据，Controller用于连接Model和View层，这种概念是比较公认的。但具体实现如何就有较大的争议了。
还有一种概念是软件的三层结构：用户交互层（UIL）、应用逻辑层（BLL）、数据访问层（DAL）。通常认为MVC是用户交互层使用的一种模式。但实际应用中MVC似乎又泛化了，广泛指代类似的、Model和View分离开来的、三层的结构。
一些实现中，Model实际是数据实体的集合，仅用于从数据库读写数据，业务逻辑主要在Controller层；另一大类实现，则是Model层存放数据和相关处理逻辑，Controller仅起到路由的功能。
MVC模式没有确切的“标准”，主要目的是实现View和Model的解耦，所以M、V两个模块不变，衍生出了一些MVXX模式（MVP、MVVM等）。
而对于游戏客户端来说，MVC模式主要指代在UI系统方面，View层和Controller层的区别看起来比较模糊。游戏中承载UI元素的GameObject (UGUI) 或 Node （Godot UI）， （后简称GameObject），归为View层是没有疑问的。
模糊的MVC模式的两种理解
- 在脚本中对UI元素进行的组件绑定、响应绑定、对UI元素进行的一系列复杂的操作（游戏追求的画面效果明显比传统用于显示数据的软件复杂的多）也是可以视为View层的。响应绑定的内容，就说不清楚了。如果单独建一个Controller层，View层接受用户输入后（由于游戏引擎的预处理，在代码中直接对UI组件绑定响应函数，已经是一层转发了）调用Controller的方法，Controller调用Model层的逻辑。这样的好处是“Model与View解耦，在Model需要更换时，只需要修改Controller中的代码”（模仿网络常见论调）。
- 但是，如果把
GameObject视为View层，把上面说到的那个代码脚本视为Controller层，在代码中的响应函数直接连接Model层的逻辑，Model需要更换时，只需要修改Controller中的代码，好像也没什么问题。
那么考虑这两种结构的主要区别，前者多一个单独的“Controller”出来，View传递的事件由中转Controller接收，如果每个“View”对应一个“Controller”，那么通信更复杂了，似乎完全没有必要；如果每个“View”对应多个“Controller”，这个“Controller”就成为了一个公用的模块。在web开发中是很常见的，一些框架通过“Controller”对参数进行判断，返回相应的“View”(ASP.NET MVC)。但因为游戏开发的特殊性，如果存在“View”层的代码脚本，也通常是一个界面就对应一个绑定脚本。除此之外，前者可以在“View”层代码中单独存放UI组件相关的一些数据，后者则不行。
目的到底是什么
之前业余用过一个UI方面的MVC框架（类似上面说的前者），可能是工作经验还太浅，理解不深，或者种种原因，做了错误的判断，但感觉的确不如后者好用。
最近也浏览过几个游戏框架的设计文档，这些框架充分考虑了通用性，即使用不同的UI系统、甚至使用不同的游戏引擎，在代码中预留的位置做好相关适配就可以用。
但并没有遇到这样集中的情况，工作中的开发就确定依赖某个游戏引擎，依赖某个UI系统，并不需要频繁更换这些东西。
而个人开发来说，要做一个独立游戏的话，依赖于某个游戏引擎也是肯定的。考虑那些不使用代码编程，仅用DnD模式制作游戏的开发者……即使一套框架再通用，好像也没什么用武之地。
就个人而言，最终目的还是要做一个游戏出来，而不是做一个框架，相关理念好的学习，做不到的就舍弃，看看就好，越犹豫不决，拖的时间越长，就越难把东西做出来。就Model层和View层，无论是用一个全局类来存储也好，还是分模块来存储也好，这两层尽量分离是毋庸置疑的。剩下的怎么顺手怎么来吧。至于结构的优化、效率的优化、日志追踪等等等等，首先知道有这回事，等demo做出来之后再去做吧……