我知道数据绑定(bind)通常用于 View 和模型之间的绑定(bind)。所以它经常用于 UI。但是，同样的数据绑定(bind)技术也可以用于非 UI 上下文。
通过数据绑定(bind)在非 UI 类和对象之间绑定(bind)属性是可接受的还是不好的做法？例如，两个普通对象可能希望同步它们的属性。在这种情况下使用数据绑定(bind)是否合理且可以接受？
最佳答案
这是一个很好的问题。
一般来说，我不认为数据绑定(bind)是一种同步形式。这个想法已经存在了很长时间，但真正让它爆炸的是早期尝试做动态网络应用程序的效率非常低。 90 年代后期的一项指标研究表明，三分之一的程序员时间用于从数据库中提取数据到表单，然后转换从用户那里获得的输入，并将其推回数据库。不久之后，您开始看到许多以数据绑定(bind)为核心的框架，例如 JSF。
如果您有需要同步的对象，通常如果它们具有相同的结构，那么您只是在做序列化时要做的事情:编码/解码。如果你看一下 Objective-C 中的 NSCoding 协议(protocol)，你会发现它表面上是一种非常简单的方法，但隐藏了一个巧妙的设计:编码器/解码器只处理属性，所以实体不知道它们是否是以 JSON 或 XML 形式写出或写入数据库。您可以在一个下午的时间内进入一个具有巨大领域模型的大型项目并添加 JSON 支持。
Java 世界的趋势是追逐神奇的自动脱水器/再水化器的梦想。因为 Java 支持反射，所以很自然地:“嘿，我可以去获取所有属性并将它们写出来，然后再读回它们。”在用这两种方法做了很多工作之后，我再也不会做反射(reflection)了。编码协议(protocol)方法的忠实拥护者。
因此，如果您最简单的情况只是编码解码，例如从远程到服务器化身(在必须支持共享数据库中的共享状态的移动应用程序中很常见)，那么您可以将其建模为在一侧编码的对象并在另一方解码，坦率地说，它们可以用不同的语言进行编码/解码。
通常，同步很快会变成其他问题，例如“如果我只想发送新内容怎么办？”我做了一个大型移动应用程序，在那里我们做了一个严肃的同步器，后来我想我很惊讶没有严肃的项目来做与语言无关的同步与更新、差异、版本等隐含的所有语义变体。
如果您的图形不相同，您需要在两者之间使用一个适配器。我认为这是使编码器的论点非常有说服力的另一件事，因为适配器必须介于两种类型之间并执行映射，这与大多数事情一样，可能会变得非常复杂。在编码器方案中，侧面的操作比反射方案更容易。
适配器的一个有趣之处在于，无论您将它们想象成事件的，还是静态构建过程的一部分。我倾向于将它们视为后者，调解器是同一事物的主动版本:需要保持彼此不知情的两方，但必须纳入合作计划。
关于design-patterns - 数据绑定(bind)只用于 UI 吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14098554/