MVC和ECS两种设计架构的初浅理解

---

MVC模式

MVC由Model、View、Controller三部分组成，分别负责数据的存储、视图界面的显示、业务逻辑的处理。我理解分为下面几个部分：

1. 用户在View层下达指令，View层把指令传给Controller层，或者是Controller层监听了View层，只要View层被下达指令，Controller层立刻处理与该指令有关的业务逻辑。在Controller层处理Model层的业务逻辑数据，Model层可以理解为数据和状态的存储；然后Controller层同时给View层传达数据结果的表现，驱动刷新View层的表现。

2. 当服务端发送数据给客户端的时候，可以分出一个Service层，然后是View层把Service层发过来的数据存储起来，Controller层可把Model层的数据表现传给View层表现，但是有些可以是Model层存储的数据直接给View层去读取。像比较简单的数据显示，没有太多业务逻辑的，也不是很必要通过Controller层去驱动刷新。

MVC结构图

优点：比较好的降低代码的耦合度，可以达到界面、数据、逻辑分离的效果，三个模块分别负责表现、存储、逻辑，各司其职，哪个模块出问题只需要去修改那一个模块，如果表现要多样化，只需改View层就可以了，同理，存储和逻辑需要改变就分别去找Model模块和Controller模块，这样就易于代码的维护和拓展。

缺点：如果是应用于比较小的项目或者功能上，就会显得过于复杂，比如点击一个按钮切换图片，这样实质上一个View层就可以了，逻辑和数据都可以写里面，要是分开写还降低开发效率。还有就是也不能做到给数据层和视图层完全的解耦。

---

ECS模式

ECS由Entity、Component、System三部分组成，分别是实体、组件、系统。

1. 基于组合优于继承的思想，我把实体理解为一个游戏物体，组件理解为数据，把众多组件挂在或者说组合在游戏物体上就是把数据给游戏物体，然后系统就像个CPU去处理各个物体的数据，从而引发一些行为。
2. 一个游戏物体有了这些组件有了数据就可以有一些状态，比如给了一个游戏物体弹性的组件，游戏物体就可以有弹跳这个状态，但是弹起来这个行为是由系统去控制的，系统负责处理游戏物体的行为，但是系统本身没有状态。如果要把游戏物体上弹跳这个状态去掉，系统去控制把游戏物体上的弹性组件去掉了就可以了。这样看起来似乎能很方便的管理游戏物体，游戏是由各个游戏物体组成，这样从而达到很好控制游戏。
   

ECS结构图（此图源于网络）

优点：组合优于继承的思想，能很好的降低代码的耦合度，可以将数据更有效的组织，提高CPU cache利用率，从而节省性能的开支，ECS自己有一套多线程调度系统，易于做多线程并行。

缺点：不能很好地用来开发UI交互

---

总结：我感觉这两种架构方式并不冲突，可以视情况并同使用。MVC比较适用于UI交互的设计，ECS比较适用于处理游戏物体之间的业务逻辑关系。