如题 。大佬求解惑，自身认为，这两种都是组织工程的方式
MVC很清晰的划分了：数据 试图 控制器
组件：creator或者老unity的都是component兼容了 data和func 貌似不需要什么model层了
在写东西的时候 老是会被一些东西控制束缚
还有一个问题：组件化的时候，我在一个组件里想要操作其他组件的数据。。就必须持有这个组件往往，这样感觉写起来有点耦合
没有人讨论下么 各位 自顶
个人一直觉得MVC一直就不太适合cocos…
额 怎么个说法 老哥 讲一哈
还有一种东西叫ECS
老铁这我懂。 大家可以说一下各自的想法之类的
再顶一哈 希望有些大佬分享一些经验
要理解mvc的本质是数据驱动，如果理解这一点就简单了。
就是当数据变化时视图同步变化，所有的框架就是为了做到这一点。
那么Mode只要放所有的数据，Controller负责如何get和set数据的时候一些操作，对数据的一些自定义操作（比如服务器给你的数据需要在前端背包排序之类的），然后分发给View。view做出变化。
理解这样的结构，就理解了除了View对于每个引擎是不一样的，Mode和Controller都是一样的。
mvc关注点不是数据驱动，而是oop解耦，ecs关注点才是数据逻辑分离。你概念就搞错了，ecs可以说是一种范式了。两者完全是讲述不同层面的东西，没有先后。ecs和oop编程是同一级别比较的概念，mvc是解决oop编程里耦合而出现的。
这几天做了很多思考也看了很多文章问了一些人。下面是一些总结 帮助需要的同学，可能说的不是很准确，希望大家补充：
首先，MVC也好ECS也好他们都是一种编程的范式，或者说你组织代码的方式。然而他们的层面不同，也就是说不是一个层面的东西。
MVC：用来解决UI交互方面的成熟的经验体系，是一种分层的设计。
ECS：是一种对象组织的方式，比如继承也是一种处理对象关系的方式。而ECS就是组合的方式来处理对象见关系的，还看到了一种说法：
Entity system architecture derives from an attempt to resolve the problems with the game loop. It addresses the game loop as the core of the game, and pre-supposes that simplifying the game loop is more important than anything else in modern game architecture. More important than separation of the view from the controller
也就是说ECS这种方式目标是用来尝试处理游戏循环问题的。并预先假设简化游戏循环比现代游戏架构中的任何其他东西更重要。比从控制器分离视图更重要。
同样，还有很多的架构，比如分层设计的系统架构等等。
简单的总结来说，他们不是一个层面的，MVC是一种分层的针对UI交互的设计，而ECS是一种处理对象关系的方式。
为什么我上面会困惑，就是我把不同层面的东西放到一个平面上来思考讨论了。就像你有一个衣服柜子，用它来放鞋子okay么？是的可以放，但是会不会别扭？会的。这就是我的一些困惑，可能这个例子并不恰当，但是用来说明不是一个层面的东西应该足够了。
还有补充一点楼上说的。
ECS其实更是解耦的终极方案，处理更复杂问题的一种更好的方案。另一方面MVC并不是不关注数据驱动，想要使用好MVC数据的驱动也是必须的才能更好的解耦。只不过MVC更关于也更适用于UI方面的交互罢了，当然这也是一种经验模型，后来的MVP以及MVVM都是一种优化或者特别场合的提升。
再总结下：MVC以及ECS不是一个层面的东西所以理论上不会有冲突。
至于适用场合，个人感觉：如果涉及ui交互比如某一个界面显示某些东西，同时这个ui可以出发一些事件这种还是MVC更方便一点，因为你用ECS会发现你无从下手，比如你是单独写个view的组件？这个view触发的事件呢？以及这个view所依赖的数据呢？都写到了一起？你会发现写着写着都写到了一起结构很乱。可能目前我并没有找到什么合理的方式。关于ECS的使用，其实目前如果基于creator来开发，并不是纯粹的ECS思想而是类似unity老版本的一种C-S的结合体的组件。什么时候以及什么场合使用，个人感觉是GamePlay的场景，引用wiki的一句话：Gameplay is the pattern defined through the game rules. 也就是游戏玩法。因为游戏的玩法复杂度很高，变化很多，这种时候利用组件的方式去实现游戏玩法，能保证各种玩法的组合，这样使用更加方便贴切。
1赞
突然有了一个想法，就补充下。我说ECS是一种处理对象之间关系的方式。那MVC呢？这个不是么？我们都是面相对象编程，View是个对象么？Controller是个对象么？这个不是处理对象见关系的么？其实我想回答，是的。我们几乎都在处理各个对象。为了实现某个业务，把各个对象组织起来。好的代码就是轻度耦合实现。
但是，我想说，还是重点不同，其实MVC，我们本可以用一个view代码来实现所有，在view的代码里做很多处理控制。我们也能实现一个对象完成业务，可是为了应对频繁变化的需求慢慢演变出了MVC，它是一个解决方案。这就是侧重点以及面向的层面不同。
而ECS处理起真真切切的各个对象的时候，就会很自然而然。组合各个对象成某一个或者某一类对象，或者更合理的应该是，组织各种各样的数据？比如position组件，组织x，y坐标数据。这种面向数据的东西，或者说更注重这个数据的东西用ECS这种组件的方式更贴合。这个可能就设计到了为什么用组合而不用继承的这一系列讨论。比如这篇文章：What is an Entity Component System
1赞
仅仅基于oop解耦的mvc可以说都是垃圾，没有任何实用价值，ecs只是实现数据驱动的一种方式，数据驱动不等同与ecs。只要记住一点，再游戏中用的的任何设计模式目的只有一点，数据驱动。别的目的都是垃圾添麻烦的，走入这种误区只会写一堆没用的繁杂的代码在里面。
任何东西都没有纯粹的不用继承，守望先锋那个分享你可以去看看，基本上是现在ecs的巅峰了，还不是用了继承。只能说能不用继承就别用，任何的设计模式，对于游戏来说就是要做到数据驱动，最好是数据只要塞进去，就能展现任何时刻的完整画面。
MVVM会好一些
无意中看到这个帖子，感觉深度想一想还是挺有意思。我也来发散下思维。
-
组件的概念来自于ECS，也就是是实体组件系统。拿我们身处的这个复杂世界来打比方，那么实体就表示你、我、大楼、汽车、手机……任何实体都能拆解出若干个组件，比如汽车有车架、轮胎、地盘等组件；如果再将轮胎看作实体，它将包含胎皮、钢圈、螺丝等组件。也就是说再复杂的系统最终都能拆分出最简单的组件出来。也就证明了ECS这套理念是无懈可击的，是可以拆解任何复杂的系统的（解耦）
-
再来说说MVC。我们先用枪来打比方，枪的子弹数量是model，枪的模样是view，板机就是controller。当士兵将子弹装入弹夹（model变化），引起枪的模样变化（view的变化）；当士兵扣动扳机后（view变化调用controller），子弹发射出去，导致子弹数量变少（model变化）。这就是一个mvc模型，但是你会发现这里面有很多“Bug”。比如子弹数量的改变直接导致了枪外观的变化，而没有经过控制器；板机其实也是view的一部分。所以在这个模型里很难将mvc用明白，这也是很多人很难理解mvc，并且用错mvc的原因。
再换一个例子，用手机来打比方。当系统给手机发送了一条系统更新通知（model变化），手机系统相关模块（controller）控制屏幕点亮并显示一条推送消息（view变化）。用户点击推送通知，关闭了通知（view改变）并调用相关模块（controller）控制系统开始更新系统（model变化）。在这个例子中 model、controller、view很好地区分了开来，很好的演示了MVC模型。
-
可以看出MVC并不适用于任何情况，特别是跟现实世界越像的事物越不适用。而游戏恰恰是一个模拟的现实世界，这就解释了为什么MVC并不很适用于游戏的原因。而在其他行业 比如web开发、app开发，这些都是高度抽象的事物，在现实中找不到类似的实体原型，所以它们就适用MVC模型。
-
至于为什么MVC更适用于更抽象的事物？我还在思考这个问题
1赞
emm…虽然看不懂，但是还是想说大佬们nb！
不过我这种ui仔还是习惯于不讲究所谓范式，按自己习惯来设计 。。。 
组合与继承，其实都是面向对象的一种思想。组件化就是组合与继承的结合。mvc也好ecs也好，它们是一种架构思想。其实并不是一类东西，而且 组件≠ecs
不管是MVC.MVP.MVVM，最终的目地都是解耦和复用，游戏内复用的比较少，主要是解耦，ECS不太适用于UI模块，比较适合战斗模块的设计
还有，个人认为数据驱动是所有设计模式都会考虑到的，但并不是唯一，如果不解耦，数据，视图，业务代码写在一块，单元测试就不用想了，业务逻辑和视图分离开发也不用想了，代码也只会越写越乱