扯扯“Model Driven UI”

为什么我认为对于构建应用程序而言,MVVM/React是比jQuery更容易的方式?

文章比较浅,科普性质,大神们别嫌弃。

“传统”方式

用一种“传统”的思路,我们要更新页面某一个部分的UI,应该这么做:

这个例子应该是一个典型的场景

  • 拉数据
  • 找元素
  • 改属性

为什么核心在于“找元素”呢?由于要尽可能的优化UI的性能,只能做最小更新操作,那么就需要找到发生变化的那个字段所需要的元素,单独对其进行操作。

所以jQuery的核心就在于query,首当其冲就是它能最快捷的帮我们query出需要的元素来,很好的满足了一个JS库的核心需求。当然它的另一个优势就是它的API设计得太简便了,简直是不会JS都能用,入门成本之低令人发指。

这么做的问题

一句话

UI被设计为依赖Model,Model不应该依赖UI。

如果实现成贫血Model层,就会在逻辑代码里面去进行上面的query-update操作,如果是充血Model层那可能就在Model里。不论怎样,这样做都违背了上述依赖关系。

很简单,当UI发生变化(这种变化在迭代当中非常频繁)的时候,不仅需要修改UI本身,也需要去修改逻辑代码或者Model层,比方说#name这个ID换掉了,得换个选择器;比方说span变成了textbox,得把.html()换成.val();比方说整个UI层重新换了一套CSS命名规范,或者上了一个className混淆方案,可能让所有的addClass/removeClass/hasClass全瞎;比方说运营需要“重要的事情说三遍”于是同一个字段要被连续展现3次;比方说相册改版,啥没变,惟独从井字格变成轮播图了……

这些本身应该是UI的事儿——毫无业务逻辑在里面——却需要去改逻辑代码,依赖关系颠倒过来了,形成了anti-pattern。

所以现在流行说“单向数据流”,它是对上面所说的依赖关系的一个形象描述。

Model Driven UI

这概念谁说的来着,好像是Polymer。其实在12年的某个项目里,我就在尝试这个方式,当然,举步维艰。

一个很糙的方式

当时的主要矛盾是,我们也实现了单向数据流,所有UI操作都调用Business层(相当于Controller)的接口,UI保持对Model的严格只读。但Business层修改完了Model之后,下一步就非常难了,为啥难呢?因为“Model变了,Drive不起UI来”

如果Model只有一个简单粗暴的change事件,那么UI就倒了八辈子的大霉了,它根本不知道到底变了什么,没法做最小的UI更新,那么性能上基本先Say Goodbye了。

于是实践上的问题就来了,Business层在修改Model的时候需要如履薄冰地触发一个“合理地小”的事件——不能太大,这样UI大面积做无用的更新;不能太碎,这样UI还需要做一个batch更新机制。
这样的结果肯定就是事件的种类会随着use case增多而大幅度增多,而可怕的就是UI必须对这些新增的事件一一作出响应,哪怕它跟之前某一个事件差别相当之小。

这当中自然也就隐含了Model对UI的间接依赖,逻辑代码需要对UI有比较深入的了解,才会知道怎样去触发一个事件它才会“合理地小”。

有了batch update,可以把Model的change做到字段级别的CRUD事件了,但UI需要关心的事件就会呈一个数量级的增加。等于原本在逻辑代码里集中更新UI,变为了在UI里(借助batch update)分散更新——事儿没变少,就是换了个人在干。

至少是解决了一个依赖倒置的问题,UI通过字段来访问Model,通过事件来订阅更新自己,而Model则几乎不会对UI产生直接依赖了,极端一些,Model对于UI是不是DOM都可以不关心了。

没那么糙的方式

现在有了MVVM和Virtual-DOM了,batch update也都是标配,Business层可以肆无忌惮的对Model进行任何粒度的CRUD。UI也不需要监听Model上的各种事件了——简单的说来,虽然整个数据流没有变,但是每一个环节都变简单了。

所以MVVM和Virtual-DOM解决的问题是数据绑定/数据展现吗?是,也不全是。更深究地说,它们解决的问题是帮助UI和Model之间“脏活累活谁来干”的问题——都没人干,于是只能让框架干了。从此以后,

对于Model而言:“老子就管写,你爱读不读。反正我的值是对的,用户看到展现不对那都赖你。”

对于UI而言:“老子就歇着,你爱咋样就来弄我两下,但是活儿得好,别让我太累,用户嫌卡那就怪你。”

至于Model如何Drive UI,Angular(脏检查)、React(Virtual-DOM)用的办法是主动的发现Model的变化,然后去推动UI更新;Avalon、Vue基于property getter的做法是被动的等Model发生变化。
除了Virtual-DOM以外,都需要对UI进行预处理,解析出一个UI Element -> property之间的依赖关系,知道每一个Element依赖了Model的哪个字段。把这张图反过来,就知道当一个property被修改时,它会影响那些个Element,从而实现最小更新。
而Virtual-DOM的最小化patch方案是通过tree-diff计算出来的,基于现代浏览器“老子for循环跑的飞快”的霸气,执行tree-diff的速度很理想。于是就直接不需要构建依赖关系,用起来更简单粗暴;进而在需要的时候有一定的优化空间,可以通过immutable这种方式来快速跳过tree-diff当中的某些环节。
所以在精心优化的情况下,Virtual-DOM应该最快的无疑,property getter有更强的适应性,天生就很快,但从外部去优化它很难。
React另一个优势是它的启动速度,由于不需要构建依赖关系,甚至是连parse模板都不需要(这一步相当于直接在构建JSX的时候已经做好了),它启动步骤就短多了,夸张地说,直接render就出来了。
使用property getter的方案对于Model层有非常微弱的侵入性(相比Knockout那是低多了),使用脏检查和Virtual-DOM对Model层都几乎没有侵入性。
当然上面所说的性能差异其实都没有那么大啦……只是因为我自己写过virtual-dom玩具,也看了Vue的源码,一点小结而已。

理想和现实的差距

在一个足够复杂的场景下,如果能践行Model与UI的依赖关系,程序的可测性(React还是谁来着,也管它叫Predictable,可预测)就有了一定的保障。

但是,很多情况下,没有那么理想,比如

  • 很多Model被展现一次就没事儿了,压根儿就没有动态修改
  • 很多Model只被在一处展现,因此它动态修改的时候,在UI改和在Model里改,工作量是一样的
  • UI的调整并没有那么理想化,无法解释为纯UI的问题,几乎每次调整都涉及到业务逻辑的调整
  • 无所谓视图逻辑和业务逻辑,我们认为展现形式是业务逻辑的一部分,并不是什么卵的视图逻辑

个人的感受

  • 程序怎么写,还得看活儿
  • 做Web App和做Web Page,取舍还是差别大
  • 怎么算Web App怎么算Web Page,还得看老板怎么想
  • 如若无所谓模式,无所谓架构,那一切都是白说,反正It works
  • 面向工资编程,终究还是为了出活儿快、下班早,需求变时别骂娘,早日升职加薪,当上总经理,迎娶白富美,走上人生巅峰
1 1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部