了解了，你这种方式适合管理大型项目，但是如果没有类型提示，那就用起来就有点麻烦，单独一个事件键 enum 是没有太大用处的
业务复杂了是不能这么写的，肯定是多种模式的组合，不要拘泥于一种
待过几家基本都是MC-V的结构比较多，视图层单独拿出来，MC不分家写一个类里。标准的MVC还没遇到过，也可能是因为我重度项目接触的相对少一些。
比如视图层叫XXXPanel，控制层和数据层叫XXXSystem或者XXXModel
你们有没有见过：
Controller 里引用着model，引用着View
Model里 引用着Controller， 引用着View
View里 引用着Controller，引用着Model
Controller能广播消息，Model能广播消息，View里能广播消息， 一个控件监听着3大消息，还依赖于执行顺序
整个项目各个类的关系是一张大网，你中有我， 我中有你
如果你都见过，并且能处理的很好，说明你的工作经验够了，百屎丛中过，片屎不沾身
5赞
招人么 马赛克
我在的公司目前不招人，抱歉哈
好吧 谢谢大佬
见过。。。。。。
这… 我感觉出问题要死人的,理不清!
第一次见的时候我是一脸震惊的。然后就跟着项目随大流了，反正不是自己的一手项目就是别人怎么写的就跟着,框架严谨大家遵守规范我就严谨,框架飘逸大家起飞我也跟着飞,主打一个九阳神功
对于以上的b和c，数据处理的代码，有些会放到model里面，有些会放到controller里面。而对于同一个项目，不同的人，可能理解不同，有些人会放到model，有些人会放到controller里面，甚至放到view里面进行处理。
我还真是把view需要的数据放view里了，原因是，我觉得这样才高内聚，而且界面大多不通用，一般会有一些通用的剥离出来的ui组件
英雄所见略同，通常情况我也不会写Controller，因为业务不复杂的情况下，写一层Controller过于臃肿，我只需要一个对应的M存储数据就行了。如果某个功能庞大且复杂，涉及到多个View互相交互，那我才会加个Controller层调度，不然在View里调用另一个View真的过于恶心
这结构肯定不行啊
游戏前端逻辑这点复杂度,用这个架构除了增加开发难度外,说实话没见过好到哪去…一个数据中心+消息系统就能搞定的事,非得搞这么复杂…
怎么这个贴又被顶起来了？ 100多个模块，600多个界面的项目复杂度够不够 
入行快10+年了，见过好2个项目生搬硬套MVC,但是很明显C这一层，真的很废，很鸡肋
最后我也总结了下我所有经历过的项目还有自己的理解，我也认为MV两套足够了，C强行插进来除了蹩脚增加工作负担没啥正面作用
至于网络请求协议完全可以另外加个xxCenter来处理