主要是没用过 不知道大家是咋用的 这种方法有没有坑
我选2。1这种会产生大量的代码耦合，我的宗旨是把数据和UI隔离开，UI层可以直接访问数据，但是数据层通知UI全部通过事件。
这是 1 的那种方法么？
是不是 各有优劣 ?如果没啥硬伤的话 我就随便搞了 我也倾向2 感觉用1的方法 写的代码有点多
控制UI的数据必定会产生耦合不可避免的，不像功能性模块的数据或者是算法数据，这些跟UI毫无关系的。
就算你通过事件去通知，也只不过是吧耦合转移到了事件上面。把UI跟数据的代码分开便于阅读和理解才是真正的作用，方法一通过get 和 set其实跟方法二没啥区别，就是方法一轻松一点，代码好看一点，方法二就要写一大堆事件和回调，不美观。
1赞
耦合怎么转移到事件上面？事件就是消息通知啊，哪来的耦合，至少可以避免一堆类似如下的代码：
let uiCtrl = getUIById(id)
if (uiCtrl != null) uiCtrl.xxxx()
这种代码太丑了，我是不愿意这么写的。
不管怎么样都是数据驱动显示，怎么驱动？ 可以事件 观察者与订阅， 从性能来说update肯定是不行，另外我各人非常不喜欢把显示对象与数据绑定
实际上我对这里 有点疑问 ，真的会非常耗性能么？ 对性能有多大的影响呢？
首先，放update里没必要。因为数据的变化必然是自己可控的，那么何必每帧都去刷新呢？至于是派发事件还是直接对象调用接口，这种我觉得根据实际情况和个人习惯来，我个人是两种都有在用，比如这份数据有很多地方要使用或者使用的地方不方便获取数据，我就会派发事件。如果数据只是个别类在用，而且能比较方便获取，我就直接对象调接口
你需要MVVM
最坏情况每帧更新显示，那么每帧都会有新的dc ，你说耗性能么
MVVM 用过然后放弃了，太难处理复杂一点的数据更新。 引用里用的方法就很好
第二种比较好
1、单向依赖
2、显示（VIEW），依赖数据和逻辑
3、不要在Update里无脑刷新数据（除非真的有必要），容易被开除。
说个自己构思的模块架构，总体结构为MVVM
模块架构
-
业务
- ViewModel： 视图模型，负责业务逻辑和视图控制，持有View以及Model，可通过View访问ViewData
- Model：业务数据
-
视图
- View：视图，持有ViewData，负责ViewData与视图的绑定以及视图方法提供，所有用户输入以 event 方式传递给ViewModel
- ViewData：视图数据
view可直接访问view data，也不用像传统的 MVVM 先传递给 VM，VM 再传递到 M，view 单向隔离 viewModel，而 viewModel 也可以任意切换 继承于viewBase 类的视图类
一直用2，挺好用的
大部分情况用1，修改数据的时候直接刷新UI，特殊情况用2，比如公共UI，奖励等
看项目规模吧。
如果只是非常小规模的项目，逻辑非常简单，简单的几个ui刷新数据，耦合一下问题也不大。比如。。。计算器？？？
一旦数据逻辑复杂度上升，一定记得要将逻辑和视图分开处理，推荐使用消息机制，如果极致追求效率的话，不要用字符串作为消息id。
看着第三点，然后看了看三年前的代码，觉得三年前的老板真的友好~
大部分情况下用2，极少数用1。
因为用的基本都是ts，所以写一堆的消息也不会说很复杂，做好命名甚至能提高开发效率。