见过。。。。。。
这… 我感觉出问题要死人的,理不清!
第一次见的时候我是一脸震惊的。然后就跟着项目随大流了，反正不是自己的一手项目就是别人怎么写的就跟着,框架严谨大家遵守规范我就严谨,框架飘逸大家起飞我也跟着飞,主打一个九阳神功
对于以上的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来处理
大概83.5分
我也不知道自己写的是什么设计模式了。。。我的model是状态子类；control里面保存一个model的基类，事件注册在control里，切换model后，同一个事件对应执行的逻辑就不一样了。我也不知道这是什么模式了。主要是按钮有些时候能用，有些时候不能用，有些时候（不同状态）点某个按钮会产生不同效果，不想写各种枚举去判断。 
代理模式吧