我有一个 WPF 应用程序，它将十几个 xml 配置文件的编辑封装在一个地方，这样部署工程师就不必知道哪些地方可能会或可能不会更改。目前，每个配置都表示为自己的对象，其中包含将各种 UI 项更新为标准 get 和 set 函数的逻辑。
另一个功能是应用程序应该读取这些配置文件的旧版本并将任何更改的值复制到新安装。真的很简单，因为我们使用每个文件的对象表示。
我一直在研究 WPF 数据绑定，虽然它看起来非常适合读取和写入 XML 并显示在各种应用程序控件上，但我无法弄清楚我将如何实现复制部分。使用数据绑定会不会走错路？
【问题讨论】：
标签： wpf xaml data-binding
“我应该在 WPF 中使用数据绑定吗？”这个问题的答案。几乎总是“是”。真正的问题更多的是，“我应该使用 WPF 数据绑定做什么？”
听起来您的应用程序的架构目前是：
XML <--> Object Model <--> UI Controls
在 WPF 中，您需要使用数据绑定将对象模型连接到 UI 控件。当前对象模型中复制 XML 文件并更新其内容等的所有功能，就 WPF 而言，所有这些都发生在另一个世界中。
如果当前在对象模型中实现的方法对需要推送到 UI 的对象属性进行了更改，事情可能会变得更复杂一些。例如，您可能会发现要创建Command 对象以将这些方法公开给UI，然后需要实现一些机制以在方法更改对象的属性后引发PropertyChanged 事件。根据您应用程序的整体架构，您可能不想在您的对象模型中集成 WPF 对象（例如命令）或实现属性更改通知。
这会让您进入 MVVM 模式（Joe White 提到的“视图模型层”）的领域，这是一种封装命令和属性更改通知（以及 WPF UI 需要的其他内容）的方式，而无需修改底层对象模型。没关系。第一次做的时候有点不知所措，主要是因为当你开始研究它时你会找到的信息会告诉你解决你可能没有（或可能还没有）的问题的方法。但实际上并没有那么糟糕。
【讨论】：
WPF 非常面向数据绑定，因此通常使用数据绑定可能不会出错。
但是，您似乎特别询问了 到 XML 的数据绑定。 而且我不明白您为什么要这样做。您已经拥有可以读取 XML 并将其写入配置文件的对象。不要通过添加以不同方式执行完全相同加载的绑定表达式来复制该知识。特别是如果您的配置文件格式定期更改，您不希望维护一份以上的读取和写入代码的副本。
只需将您的 UI 绑定到您已有的对象。如果它们足够简单以至于您正在考虑绑定到 XML，那么听起来您没有任何花哨的逻辑——您应该能够直接绑定到现有对象上的属性，甚至不需要添加viewmodel层。
【讨论】：