前些日子也有一个MVC贴，讨论的比较激烈，我后来也有点疑惑，为什么很多人说C是没有必要的。
我后来仔细研究了一下MV系列框架的演变，原来我这边的MVC理解还是有误，我们一般用的框架，实际上叫做 MV（C+F），F是Facade，也就是Controller 同时有ViewController，GlobalEventHandler，NetHandler 和 Module Facade 的功能。是一个全局的模块入口。所以是不可或缺的一部分，并不能被取消。
我贴一下我记录的MV系列框架的变化：
MV系列框架，主要分为几类，根据演化历史逐步递进：
- MV ： 简单的Model-View框架，又叫Document - View 文档视图框架
- MVC：在MV之间，新增Controller组件，粘合View 到Model 的交互
- MVP：在MV之间，新增Presenter组件，粘合View 到Model 的交互，与Model修改时View的更新
- MVVM：在MV之间，新增ViewModel组件，通过数据-控件绑定，将View本身数据化。
这个怎么讲呢，设计模式是解决问题的，核心就是解耦，降低学习、开发、维护成本。
找到一套自己认为简单 易用的框架就好了。
哪怕多“.”点一个属性、多打一下断点、多传一个参数，如果你觉得用不着那样子，可以简化，尽量简化。
我写这个只是觉得我从业十多年，个人认为比较便捷的一种方式。楼上有也有一哥们儿他也有一套他认为很方便的框架体系。
反正这些都是可以多交流一下的。
MVC 在划分的时候，如果那个V 是自动生成的，那就相当于没有工作量，没有工作量的东西就不用划到MVC 里了。
MVC 应该这么划分：
M：数据层（不会自动生成，你得设计编写代码）
V: 预制体，工作的时间花在做这个预制体。（你自动生成的节点访问脚本，只是预制体换了一个等价表达而已，本质要把你的自动生成脚本理解为那个预制体。）
C：预制体上绑定新的控制组件，它去处理各种逻辑，包括调用你自动生成的脚本。
所以实际模式是 M+预制体（自动脚本）+C。
所以从脚本工作量的角度看。只有M和C。
就是你这个意思，因为V是生成的，我不会手动去修改其代码，基本上只做M和C的操作.
嗯，你的模式是简洁高效的
你这种我知道，不过有几个问题
使用mvc很多人分不清哪些是数据逻辑，哪些是视图逻辑，很容易失控，最后乱调一通。所以还是推荐上mvvm
你这个其实是做了一层封装，生成了属性，使用的时候不用find了。更像是MVP。因为你这个view和model是完全解耦的。
是的，每个人理解的都不一样，然后都往自己习惯的方式改造，所以可能已经不是mvc了。
我那种方式下，不会认为预制体是V，而只是把预制体作为一种元数据（metadata）看待（完全不挂脚本）。所以我的V是单独的类，与预制体进行控件绑定，C是模块接口。
不过如果元数据里面本身带有逻辑的话，例如蓝图，也可以看成V，我UE的框架，就是UMG蓝图是V，CPP的基类是Presenter。
用过MV(C+F)也用过MVC（也说不清是不是标准的MVC，每个视图都有一个C那种）对比下来MV(C+F)更好用一些，这种框架基本都是处理UI界面C+F的方式不用每个界面都必须新建一个C，C更像是大管家，每个V都绑定一个C的方式很啰嗦，而且大部分情况下业务和逻辑也很难特别清晰的分开写，一笔糊涂账，更麻烦的点在于C和V还要事件通信业务流程并不清晰
其实还是喜欢doc-view .MVC太啰嗦了, 多出一大堆接口
好吧。
解耦一般。
mvc相对小游戏有点笨重了，不够敏捷开发。后端用这一套挺好。游戏开发一定是组件模式好一点，组件优于继承。入职不久的开发培训就讲了这个
大多数都是 view(view+control合并) + m，，，
同意这个老兄的说法,实际用的时候,发现cocos 是组件开发,mvc.只做数据分离+部分功能逻辑控制放在c端最有效率. 如果把v端的各种动作动画等等的UI逻辑 绑定到cd端控制,反而冗余复杂化了.我开发用监听来避免这个绑定. 我看很大部分项目时把V与M, 绑到了C端.这个确实是MVC结构,但是用起来不是很好用
你拿ECS来做UI？你得写多少个组件类？
MVC/MVP，加载到实例化需要一行代码new一下就出来了，你是不是调一个加载接口，再new了过后，再传对应的组件？而且组件还不知道要传多少个？
组件式开发不是不好，要看用在什么地方，如果是做战斗avatar,AI ,技能，是很好用的。但用在复杂UI那才是真正的臃肿，繁琐。
我这种其实真正的只需要写C和M，V层基本上不会去动它。（即使遇到UI需求的改动，也只改C 的代码比较多，如果数据上的结构变了，也会不影响的）
我提ecs了？觉得好用你就好好用