我知道数据绑定通常用于视图和模型之间的绑定。因此它经常用于UI。但是，也可以在非UI上下文中使用相同的数据绑定技术。
非UI类和对象之间的绑定属性是通过数据绑定可接受还是不好的做法？例如，两个普通对象可能希望同步其属性。在这种情况下使用数据绑定是否合理且可以接受？
答案 0 :(得分：1)
这是一个非常好的问题。
通常，我不认为数据绑定是一种同步形式。这个想法已经存在了很长时间，但真正让它爆炸的是，早期尝试动态网络应用的效率非常低。从90年代后期开始的度量研究表明，程序员时间的三分之一用于将数据从数据库传输到表单上，然后转换从用户获得的输入，并将其推回到数据库中。在那之后不久，您开始看到许多以数据绑定为核心的框架，如JSF。
如果你有需要同步的对象，通常如果它们具有相同的结构，那么你就是按照序列化的方式做的事情：编码/解码。如果你看一下Objective-C中的NSCoding协议，你会看到一个非常简单的方法，但它隐藏了一个巧妙的设计：编码器/解码器只处理属性，所以实体不知道它们是否是被写为JSON或XML或数据库。您可以使用庞大的域模型进入大型项目，并在下午添加JSON支持。
Java世界的趋势是追逐神奇的自动脱水机/再水化器的梦想。因为Java支持Reflection，但很自然地说：'嘿，我可以去获取所有属性并将它们写出来，然后再读回来。'用这两种方法做了很多工作后，我再也不会做反射了。编码协议方法的忠实粉丝。
因此，如果你最简单的情况只是编码解码，从远程到服务器化身（在共享数据库中必须支持共享状态的移动应用程序中常见），那么你可以将其建模为一边编码的对象并且在另一方面进行解码，坦率地说，它们可以用不同的语言进行编码/解码。
通常情况下，同步会很快变成其他问题，例如“如果我想发送新内容怎么办？”我做了一个大型的移动应用程序，我们做了一个严重的同步器，然后我想到我被震惊了没有认真的项目与语言不可知同步与更新，差异，版本等隐含的所有语义变体。
如果您的图表不相同，则需要介于两者之间的适配器。这是另一件事我认为编码器的参数非常令人信服，因为适配器必须站在两种类型之间并执行映射，这与大多数事情一样，可能变得非常复杂。编码器方案中的侧面操作比反射方法更容易。
适配器的一个有趣的事情是你是想要它们是活动的，还是静态构建过程的一部分。我倾向于将它们视为后者，将Mediator视为同一事物的主动版本：双方需要彼此保持缄默，但必须将其纳入合作计划。
答案 1 :(得分：0)
当然可以接受。您可以在mvc中找到它，但它不仅限于UI。例如模板。 jasper报告使用它来生成pdf文件，excel等.spring将java类和对象绑定到xml配置。当编译器无法帮助你时，你总能做到这一点
但我认为这个概念仅在静态类型语言中是明确的。当你没有类型并且你做'鸭子打字'这是一个大数据绑定