关于sap:深入学习SAP-UI5框架代码系列之七控件数据绑定的三种模式-One-Way-Two-Way和OneTime实现原理比较

这是 Jerry 2021 年的第 8 篇文章，也是汪子熙公众号总共第 279 篇原创文章。

(0) SAP UI5 利用开发人员理解 UI5 框架代码的意义

(1) SAP UI5 module 懒加载机制

(2) SAP UI5 控件渲染机制

(3) HTML 原生事件 VS SAP UI5 Semantic 事件

(4) SAP UI5 控件元数据的元数据实现

(5) SAP UI5 控件的实例数据批改和读取逻辑

(6) SAP UI5 控件数据绑定的实现原理

(7) SAP UI5 控件数据绑定的三种模式：One Way, Two Way 和 OneTime 实现原理比拟(本文)

(8) SAP UI5 控件 ID 的生成逻辑

(9) SAP UI5 控件的多语言 (国际化,Internationalization,i18n) 反对的实现原理

(10) XML 视图里的 button 控件

(11) button 控件和它背地的 DOM 元素

通过了三个多月不懈的致力，Jerry 终于初步把握了应用 Angular 开发企业级前端利用的技能，也通过浏览 Angular 源代码的形式，弄清楚了 Angular 的 Property binding，Event binding 和 Two-way binding 的实现原理和区别。

Angular 这三种绑定形式的应用语法如下图所示：

但咱们明天的文章不会论述 Angular 的数据绑定细节，而是持续聚焦在 SAP UI5 上。

Jerry 前一篇文章深刻学习 SAP UI5 框架代码系列之六：SAP UI5 控件数据绑定的实现原理，已经展现过这张源代码截图，第 83 行蕴含了 SAP UI5 反对的三种数据绑定模式：

(1) OneWay：单向绑定
(2) TwoWay：双向绑定
(3) OneTime：单次绑定

从第 69 行代码得悉，SAP UI5 模型的默认绑定形式为双向绑定 TwoWay.

当我第一次理解了 SAP UI5 三种不同的数据绑定模式时，脑子里马上浮现出一个问题：

在咱们的脚手架利用里，将 button 控件的 text 属性，通过 bindProperty 函数，绑定到 JSONModel 实例的 field_for_text 字段上时，应用的是哪一种绑定模式？

oButton1.bindProperty("text", "/field_for_text");

答案是 TwoWay，双向绑定。在调试器里，通过下图门路即可查看：

oButton1.mBindingInfos.text.binding.sMode.

办法 bindProperty 里创立 oBinding 对象时，把 JSONModel 的默认 binding 形式(sDefaultBindingMode), TwoWay, 赋给 oBinding 对象。

咱们调用控件的 setText 办法，批改控件 text 属性。依据 SAP UI5 数据双向绑定个性，控件 text 属性绑定到的模型字段 field_for_text 的值，也会主动被批改：

oButton1.setText("用 js 批改控件值");

从上图咱们能确认，JSONModel 模型实例的 field_for_text 也跟着被批改了。这所有是怎么产生的？

答案在 Jerry 之前的文章深刻学习 SAP UI5 框架代码系列之五：SAP UI5 控件的实例数据批改和读取逻辑介绍的 button 控件的 setText 办法里，其实曾经提到过。

下图第 1320 行的代码，执行的逻辑正是在控件属性通过 setProperty 被更新的场景下，将最新值同步到对应的模型字段中去。

在 updateModelProperty 函数外部，有一个 IF 条件判断：只有以后 oBinding 对象实例的绑定模式为 TwoWay 时，才调用其 setExternalValue 办法，将模型字段的对应值，批改成来自控件属性通过 setText 更改的最新值。

这就是控件 text 属性的变动，能传递到对应模型字段的原理。

通过之前的介绍咱们得悉，SAP UI5 控件绑定的默认模式为 TwoWay. 因而，咱们如果要测试单向绑定，须要对已有的代码进行批改，将绑定模式显式批改成 OneWay：

oButton1.bindProperty("text", "/field_for_text", undefined, "OneWay");

此时，控件 text 属性通过 setText 的批改，不会再触发 JSONModel 模型字段的变动，因为下图 3620 行 IF 语句的条件不再成立。这就是 SAP UI5 单向数据绑定的原理：数据仅仅会在模型字段到控件属性这个方向上单向流动。JSONModel 字段值发生变化后，控件对应属性会自动更新。反之，控件属性通过 API 被批改时，不会引起 JSONModel 字段值的更新。

SAP UI5 官方网站上对单次绑定 (OneTime) 的阐明：value is only read from the model once.

怎么了解这句话呢？

通过一个理论的例子来了解双向绑定和单次绑定的区别。

在双向绑定的测试代码里，增加如下两行代码：

myData["field_for_text"] = "Tom";
oModel.checkUpdate();

模型字段 field_for_text 的初始值，在第 28 行赋值为 Jerry, 而后在第 34 行设置为 Tom. 调用模型的 checkUpdate 办法后，控件的标签也主动刷新为 Tom.

JSONModel 的 checkUpdate 办法，会应用_fireChange，以事件告诉的形式，将最新的 Tom 值播送进来。

that.updateProperty 最初会调用 SAP UI5 控件的 setProperty 办法，把 text 属性的值赋成 Tom.

下图展现的 setProperty 办法，在 Jerry 之前的文章深刻学习 SAP UI5 框架代码系列之五：SAP UI5 控件的实例数据批改和读取逻辑里有具体介绍。

当初开始测试单次绑定，将 32 行 bindProperty 函数调用里的绑定模式改成 OneTime：

测试发现，在单次绑定模式下，SAP UI5 控件属性和模型字段的主动同步曾经中断了——button 控件的 text 属性，保留的是调用 bindProperty 办法那一刻，JSONModel 的 field_for_text 值 Jerry，而不是数据绑定之后，批改成的最新值 Tom.

这个行为正是 SAP UI5 单次绑定的正确体现。

那么为什么在单次绑定模式下，纵然咱们调用了模型的 checkUpdate 办法，依然无奈将模型字段的最新值，通过 change 事件告诉机制通知给控件的监听函数呢？

答案就是，在 SAP UI5 控件指定了单次绑定的模式后，它 ” 过河拆桥 ”，马上就把响应模型 change 事件的监听函数拆除了(detach，勾销注册之意)。

奥秘就在下图 3379 行代码的 IF 分支里：在 SAP UI5 控件调用 bindProperty 办法把控件属性绑定到模型字段时，如果以后绑定模式为 OneTime，则勾销控件针对模型 change 事件的监听函数注册。

如此一来，不管接下来模型字段的值如何变动，该变动的值通过 change 事件进行播送，但 UI5 控件再也不会收到该事件了，因此控件属性也不会再刷新。

Jerry 在 SAP UI5 / Angular 的理论开发生涯中，一旦遇到数据绑定出问题，总能迅速找到如何排错的突破口，靠的就是对这些前端框架的数据绑定细节的相熟。

心愿本文能帮忙大家对 SAP UI5 官方网站上解释数据绑定三种形式的阐明文字，有更深刻的了解，感激浏览。

本系列下一篇文章，咱们会介绍 SAP UI5 控件 ID 的生成逻辑，敬请期待。