不明觉厉，先Mark
应该说下ecs适用场景，并不是所有项目都可以用，比如你用ecs是为了解决什么问题，高并发还是。。。 为了解决计算性能还是？ 其实目前来看oop还是能解决所有问题 抛开3A不说
改动有点大.把之前多种类的system精简成一种了
是的，感觉逻辑重复，给优化掉了。
ECS最大的优势不是各司其职吗。数据驱动。
我个人感觉ECS不适合的原因是消耗比较大。
我不记得unity对多线程友好……
我就觉得楼主ecs写得最好一个，特别有这个缓存机制，很好解决了这个性能问题！
识货。这个框架后面还是会持续优化、完善。
之前在github上也看到了楼主的项目，对楼主的昵称印象深刻。。
ECS系统是守望先锋出来后流行的，数据分离后方便做回滚逻辑。我也正在做一些DEMO试试效果。确实js上可能ECS发挥的空间弱一些
关注点比较独特 
对我来说我是比较喜欢ecs的数据分离的能力。做过几个rpg的项目，对一堆装备角色属性混杂在那么几个文件里面很是抵触。直到了解了ecs才知道自己要追求的代码框架发展方向。
1赞
ecs的开发，本身就是反oop的
所有的实体上，都是挂着一堆组件
开发各个system,就是面向数据的开发
数据拆分，确实比较反人类，但是，我们确实没必要把数据放一起，各司其职就好了。
如果需要对数据进行统计分析，上报另外的系统就好了，这不是ecs所做的事
一个实体身上挂了太多组件后会带来很大的心智负担。比如你根本不知道这个实体身上挂了多少组件，也会不好理解原作者为什么会这样组合这些组件，也可能自己都不理解自己当初怎么这样的组合这些组件。这块不知道有何高见。
实体上挂组件，本身就是面向对象的思维，为什么实体上要挂组件呢？
实体只是一个id而已，实体自身有什么作用呢？
没有啊，数据在组件上，逻辑在system上。
理论上，我们只需要有组件，操作的是实体id为XX的组件上的数据而已。
system只关心组件上的数据，根本不关心实体是谁，只要有血条，我就搞。
我不关心血条是玩家的，还是npc的，是人物头上显示的，还是UI面板显示的。
这些不是它关心的东西。
同样，我们也并不关心实体上有哪些组件，因为你不是面向实体，或者说，面向对象编程。
1赞
不同职责的组件之间交互如何处理呢
不同组件为什么需要交互？
组件只是数据，
我没看到需求，你可以举个栗子。
站在系统的角度逻辑都是面向组件的。但是凡是流程都有个开头，必须先创建实体才能有组件。挂载组件也是挂载到指定实体上。那么还是会出现我上面说的问题。
按我自己的处理，交互写在System里面，或者单独封装个功能函数处理交互。
创建实体，本质上就是创建一个唯一id
假设组件不能脱离于实体，哪怕全局组件，也是位于一个全局实体上。
那么，创建组件的时候，必须指明实体，也就是那个id,
如果简单粗暴一点，直接丢到一个kv结构里，例如map里，key就是实体id。
实体自身，没有逻辑，因为逻辑在system里，它也没有数据，因为数据在组件里。
而对象是由它自身的数据以及维护这些数据的方法所构成。那么，实体就不是对象，没有作为对象存在的意义。
你的意思是实体身上有多少个组件并没有关系，反正实体不会去操作这些组件，组件都是分派到各个系统去处理逻辑。
对啊，实体根本不关心自己身上有什么组件，它什么都不关心