design-patterns - 数据绑定是否仅用于 UI？

Question

我知道数据绑定通常用于视图和模型之间的绑定。所以它经常用于 UI。但是，同样的数据绑定技术也可以在非 UI 上下文中使用。

通过数据绑定在非 UI 类和对象之间绑定属性是可接受的还是不好的做法？例如，两个普通对象可能希望它们的属性同步。在这种情况下使用数据绑定是否合理且可以接受？

Answer 1

这是一个非常好的问题。

一般来说，我不认为数据绑定是一种同步形式。这个想法已经存在了很长时间，但真正让它爆炸的是早期尝试做动态 Web 应用程序的效率非常低。90 年代后期的一项指标研究表明，三分之一的程序员时间都花在了将数据库中的数据提取到表单上，然后转换从用户那里获得的输入，并将其推回数据库。不久之后，您开始看到许多以数据绑定为核心的框架，例如 JSF。

如果您有需要同步的对象，通常如果它们具有相同的结构，那么您只是在做序列化事物时会做的事情：编码/解码。如果你看一下 Objective-C 中的 NSCoding 协议，你会看到一种非常简单的方法，但它隐藏了一个巧妙的设计：编码器/解码器只处理属性，所以实体不知道它们是否是以 JSON 或 XML 格式或写入数据库。您可以进入一个具有巨大域模型的大型项目，并在一个下午添加 JSON 支持。

Java 世界的趋势是追逐神奇的自动脱水机/再脱水机的梦想。因为 Java 支持反射，所以很自然地：“嘿，我可以去获取所有属性并将它们写出来，然后再将它们读回。” 用这两种方法做了很多工作，我再也不会做反射了。编码协议方法的忠实拥护者。

因此，如果您最简单的情况只是从远程编码解码到服务器化身（在必须支持共享数据库中的共享状态的移动应用程序中很常见），那么您可以将其建模为在一侧编码和解码的对象另一方面，坦率地说，它们可以用不同的语言进行编码/解码。

Typically synchronization quickly turns into other questions, like 'what if I want to send just the new things?' I did a large mobile app where we did a serious synchronizer and I thought afterwards that I was stunned there were no serious projects to do language agnostic synchronization with all the semantic varieties implied by updates, diffs, versions, etc.

If your graphs are not identical, you will want an Adapter in between. This is another thing that I think makes the argument for encoders quite convincingly because the Adapter has to stand between the two types and perform a mapping, which, like most things, can get very complex. The manipulation of the sides is easier in the encoder scheme than the Reflection one.

One of the interesting things about Adapters is whether you imagine them to be active, or part of a static building process. I tend to think of them as the latter, with the Mediator as the active version of the same thing: two sides that need to be kept ignorant of each other, but must be brought into a scheme of cooperation.

Answer 2

当然是可以接受的。你可以在 mvc 中经常找到它，但它不仅限于 UI。例如模板。jasper 报告使用它来生成 pdf 文件、excel 等。spring 将 java 类和对象绑定到 xml 配置。当编译器无法帮助您时，您总是可以这样做

但我认为这个概念仅在静态类型语言中是明确的。当你没有类型并且你做“鸭子打字”时，这是一个大数据绑定