占201楼，感觉A方案好点。
星星你个星星星星，开始喷
选择2，即使自己做也要有规范，要不然过几天自己写啥都忘了。利己利人
AB结合，
对于A， 预设甲只绑定组件和自己管辖的子节点，不绑定其余的预设。
对于B， 能用代码驱动就用代码驱动，B方便审查代码。
A提供了便捷的手段，但不能上升为理念， B还是为主的
B为主，A为辅 YYDS
这不给颁个年度最佳帖子
我的项目情况是95%B + 5%A（大多是为了支持多国语言，挂载脚本方便点），合理应用各方式的强项，为开发服务。
没有creator之前大家都用B，也没人说不爽；框架设计得体，开发一样爽爽的；不管哪种方式，不必出来个组件化编程，就将过去老的流派贬的一无是处
我感觉A好多人开发也没问题 每个组建管理自己的生命周期代码简介 用B里面各种拿节点很多费代码 A只要你做到规范 是很爽的
1赞
我觉得代码写的越精简越好。有时候一个UI界面对应多个逻辑，不介意用一个脚本专门拖拽UI；逻辑还要写一个基类也继承组件，复用的逻辑写在基类，不复用的再写子类。
框架管理部分用B，UI相关的细枝末节用A。A用的比重很多的项目多数是快速开发然后next的小游戏。小游戏用B属于矫揉造作，大游戏用A过多不好维护。没绝对，没有哪一种纯种算正途的说法。这个帖子没完了 
1赞
管你A还是B。快速搭建开发赚得钱才好
1赞
精不精简跟开发流派没关系，代码流一样可以精简，这一点并不冲突。
根据项目来，怎么写代码量小就怎么写。
因地制宜，协作人数少可以A，协作人数多就B
我们游戏的开发经历都是从B->A的吧.
都有优势的.
A方案可以脱离UI的束缚.只关注数值的修改.这样可以让策划或者美术来做UI.程序做少量调整.
B方案在后期做配置化的时候其实好些.
我个人总结来说,在需要做配置的地方,一般不要
在预制里面加入和配置相关的参数.不要让编辑器
传入参数.
我也感觉楼主的A例子不是一个好例子.这个情况只能是A方案.
就算是代码做UI年代也应该是调用move方法.而不是持有一个node.
个人认为,需要传入一个非数据给别人持有的都不是一个好方案.
因为持有放无法保证node的生命周期内都持有它.一般这种非要
持有的最好就是post一个消息.就算是传一个回调(也不好)感觉也比
传入一个node好.
哈哈，想到一块去了，我框架里也是这么处理的
大佬这个绑定怎么搞的，方便出个demo吗。。。 
后端的上班空余时间学习cocos creator 就是用的方案B，全程在看项目代码，分析项目代码。晚上到就跑跑看。有啥方便的解决方案吗
以前用B, 后来用A. 往后只会用A.
原因是: 自己方便才是王道.