MVC是UI专用的模式，适用于横向铺量的项目。游戏（非UI部分）显然不是这样的项目。
抛弃MVC迷信是每个游戏程序员的必经之路。

通常来讲，游戏项目最合理的方式是由一个主程根据项目需求制定一套新的结构和各部分的依赖关系，事先想好各部分的扩展和通信方式，上面那位说的就是一个例子。这是必须的步骤，但既然有了这个步骤，再硬套一个通用的MVC框架就是多此一举了。

也就是说，游戏正是因为结构不通用，所以才不能用MVC框架。或者说，由于游戏结构复杂度远高于MVC框架，你仅仅使用MVC框架是不能解决问题的。MVC框架里的概念当然是有用的，但只有它们是远远不够的。游戏需要用到的架构知识远比MVC这种基础玩意高得多得多。

而游戏之所以不可能设计通用框架是因为一个有用的通用框架的复杂度和使用难度会超出所有人的忍耐极限。某种类型是可以有分别的框架的，比如上帝视角ARPG，比如GAL，比如格斗，比如跑酷，比如卡牌，比如打飞机游戏。而他们使用的游戏架构自然也是不同的。

讨论这个会没完没了。

我看题主的困惑在于MonoBehavior。这个东西是挺讨厌。这样，你可以把它当作Button一类的东西处理，它只做和视觉有关的特定功能，比如震动，比如变色，比如控制动画，赋点值然后放它一边玩去，控制好它们的依赖，让它们拥有通用性。然后游戏主体是一个空GameObject上的脚本，它负责管理所有，分发事件。其他地方就不要出现MonoBehavior了。

这样的理由在于生命周期。MonoBehavior必须依附与GameObject，也就是必须要能看到，而逻辑往往会脱离于显示部分，GameObject未创建往往就需要有逻辑了。

也就是说你创建一个人物，应该先创建一个非MonoBehavior类，然后在这个类的初始化代码里创建一个GameObject然后再套上各式MonoBehavior，然后依然在这个非MonoBehavior类处理定时逻辑和其他。需要时再控制下其他MonoBehavior播播动画闪一闪之类。

这样和非Unity游戏也就没啥区别了。想干什么就干什么很自由，也不存在隐患。

---

另外我并没有针对的意思啊，比如说伍一峰将Character Manager继承于MonoBehavior其实是有问题的。它是MonoBehavior就必须依附于GameObject，那通常只能是人物资源的那个GameObject。那么我有个需求是换状态的时候切换为完整的另一个资源，那么要不是Compent复制要不是创建子级GameObject，无论哪个都不太好吧。
或者，我想隐藏这个人物，包括里面的动画啊和纯显示用逻辑，但是基本逻辑又想留着（否则什么时候才能恢复显示？），本来直接将GameObject禁用就好了，现在这样就不行了。
或者说，它虽然有状态，但并没有显示，而是一个虚拟对象。
但如果它不是MonoBehavior就没有任何问题了。

这就是我所说的使用MonoBehavior的隐患，其实很多人心中都默默的有这样的感觉吧？这个隐患也是确实存在的。当然我也不是说MonoBehavior就完全不能用，比如受创变色（切换以及根据color对所有Renderer赋值以及恢复为原材质）肯定是可以的，还有什么动画顺序播放，部件绑定。但是涉及到逻辑的部分，真的建议排除掉MonoBehavior。它确实是毒瘤。

此外有些人不喜欢MonoBehavior是因为start发生的不确定性，还有初始化没有构造函数不便。那你需要端正下思路。你看unity默认的那些组件，你会在乎它们哪个先初始化吗？你会在乎它有没有构造函数参数吗？你不会。因为它们设计成了你不需要考虑这些东西。所以如果你写MonoBehavior，就应该设法按他们的模式走，让初始化无需顾忌顺序参数直接赋值就能解决，而不是抛弃start awake自己搞个create。
而MonoBehavior的主要优点就在于可以独立使用，不依赖于环境。你建个预置拖上去设设参数就能看效果。这是它最大也是唯一的优点，它编码上的不便也都是为了让这一点成为可能。如果你的MonoBehavior做不到这一点，或者你认为不需要，那费老大劲搞成MonoBehavior又没用，何苦。