我应该使用WPF数据绑定吗？

Question

我有一个WPF应用程序，它在一个地方封装了十几个xml配置文件的编辑，这样部署工程师就不必知道哪些内容可能会被更改，也可能不会被更改。目前，每个配置都表示为自己的对象，并具有将各种UI项更新为标准get和set函数的逻辑。

另一个功能是应用程序应该读取这些配置文件的旧版本，并将任何更改的值复制到新安装。非常简单，因为我们正在使用每个文件的对象表示。

我一直在寻找WPF数据绑定，虽然它看起来非常适合读取和编写XML并在各种应用程序控件上显示，但我很难搞清楚如何实现复制部分。我是否会通过使用数据绑定来走错路？

Answer 1

WPF是面向数据绑定的，因此通常使用数据绑定可能不会出错。

但是，您似乎特别询问将数据绑定到XML。我不明白您为什么要这样做。您已经拥有了将XML读取和写入配置文件的对象。不要通过添加以不同方式执行完全相同加载的绑定表达式来复制该知识。特别是如果您的配置文件格式定期更改，您不希望保留多个读取和写入它的代码副本。

只需将UI绑定到您已有的对象即可。如果它们足够简单以至于您正在考虑绑定到XML，那么它听起来并不像您有任何奇特的逻辑 - 您应该能够直接绑定到现有对象的属性，甚至无需添加viewmodel图层。

Answer 2

问题的答案，“我应该在WPF中使用数据绑定吗？”几乎总是“是的”。真正的问题更多的是“我应该使用什么样的WPF数据绑定？”

听起来好像您的应用程序的架构目前是：

XML <--> Object Model <--> UI Controls

在WPF中，您需要使用数据绑定将对象模型连接到UI控件。当前对象模型中的所有功能都复制XML文件并更新其内容等等，就WPF而言，所有这些功能都发生在另一个Universe中。

如果当前在对象模型中实现的方法对需要推送到UI的对象属性进行了更改，那么事情可能会变得更复杂一些。例如，您可能会发现要创建Command个对象以将这些方法公开给UI，然后需要在方法更改对象属性后实现一些用于引发PropertyChanged事件的机制。根据应用程序的整体架构，您可能不希望在对象模型中集成WPF对象（例如命令）或实现属性更改通知。

这会让你进入MVVM模式的领域（Joe White暗示的“视图模型层”），这是一种封装命令和属性更改通知（以及WPF UI需要的其他内容）的方法，而无需修改基础对象模型。没关系。第一次这样做时有点压倒性，主要是因为您在开始研究时会发现的信息会向您展示您可能没有（或者可能还没有）的问题的解决方案。但实际上并没有那么糟糕。