最近写系统写的有点头昏脑胀，遂开始思考是不是底层结构有哪里不太对劲，mvc是游戏业界使用最广泛的框架，但是因为游戏本身交互行为的复杂程度远远超过一个三层式结构所包含的内容，所以严格意义上的MVC基本只用于UI层。本质上讲，游戏的UI层和写网页应该挺像的，为什么写网页的效率会远高于写游戏UI呢？后来我就去google 了一下，发现是框架和抽象程度的问题。写网页很多时候只需要处理交互逻辑和界面的响应，底层的实现好多时候都是调的接口，其实写的人啥也不知道，他只需要会调接口就行了。但是现在我们游戏里把大量的行为代码写在了控制层，而不是封装好的底层，导致代码的可复用率极低，而且非常臃肿。后来就想到了比较潮流的mvvm框架，感觉这个框架对mvc的兼容性不错，而且ReactiveCocoa用起来是真的非常清晰明了，函数式编程结合响应式变成使得逻辑内不需要去研究状态这种让人头痛的东西，只需要写逻辑就行了。但是仔细想了一下，感觉有种高射炮打蚊子的味道。游戏的数据层和界面层本质上是比较简单的，也不需要做数据双绑，那我不就是想要一个viewModel类吗。。直接从controller里抽象一个viewModel出来不是更加简单明了。再后来我发现了问题的关键点：重点不在于业务层的写法，用什么框架都是虚的，重点是底层的封装程度和controller的拆分抽象水平。mvc的c是泛指控制类逻辑，而不是指“一”个控制器。现在大家的项目基本都把网络协议层独立出来了吧，这就是非常典型的一个逻辑细化。按照这个思路，我目前的想法是把本地数据的存取这个单独抽出来做成一个类，再把界面的拼装类逻辑抽出来单独做一个类，结合之前早就抽出来的网络协议层，整体的控制器代码就会极为简洁清晰，最后剩下的都是完全不存在复用价值的纯粹逻辑类代码。
原文：https://www.cnblogs.com/SnowCoder/p/13275918.html