这是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对象。

SAP UI5双向绑定的实现原理 - 数据从控件流向模型

咱们调用控件的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单向绑定的工作原理

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

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

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

SAP UI5单次绑定的工作原理

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的生成逻辑，敬请期待。