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

问题描述

| 我有一个WPF应用程序，该应用程序将对十几个xml配置文件的编辑封装在一个地方，因此部署工程师不必知道在什么地方可以更改或可以不更改。目前，每个配置都以其自己的对象表示，并具有将各种UI项更新为标准的get和set函数的逻辑。 另一个功能是，应用程序应读取这些配置文件的较旧版本，并将所有更改的值复制到新安装中。因为我们正在使用每个文件的对象表示，所以这非常容易。 我一直在研究WPF数据绑定，虽然它看起来非常适合读写XML并在各种应用程序控件上显示，但我在弄清楚如何实现复制部分方面遇到了麻烦。通过使用数据绑定，我是否会走错路？     

解决方法

这个问题的答案“我应该在WPF中使用数据绑定吗？”几乎总是“是。”真正的问题更多的是，“我应该为WPF数据绑定做什么？” 听起来您的应用程序体系结构当前是：

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

在WPF中，您将要使用数据绑定将对象模型连接到UI控件。就WPF而言，当前对象模型中的所有功能都可以在其周围复制XML文件并更新其内容等，所有这些功能都在另一个Universe中发生。 如果当前在对象模型中实现的方法对需要推入UI的对象属性进行了更改，则事情可能会变得更加复杂。例如，您可能会发现想要创建

Command

对象以将这些方法公开给UI，然后需要实现某种机制来在方法更改对象的属性后引发

PropertyChanged

事件。根据应用程序的整体体系结构，您可能不希望集成WPF对象（例如命令）或在对象模型中实现属性更改通知。 这将带您进入MVVM模式的范围（Joe White提到的\“ viewmodel layer \”），这是一种封装命令和属性更改通知（以及WPF UI所需的其他内容）的方法修改基础对象模型。没关系。第一次进行此操作有点不知所措，主要是因为在您开始研究时会发现的信息将为您提供解决您可能（或可能尚未）的问题的解决方案。但是确实还不错。     ,WPF是非常面向数据绑定的，因此通常使用数据绑定可能不会出错。 但是，您似乎在特别询问有关XML数据绑定的问题。而且我不明白您为什么要这样做。您已经具有可以将XML写入配置文件的对象。不要通过添加绑定表达式以不同的方式进行完全相同的加载来复制该知识。特别是如果您的配置文件格式定期更改，则您不希望维护读取和写入该代码的多个副本。 只需将UI绑定到已有的对象即可。如果它们足够简单，以至于您正在考虑绑定到XML，那么听起来就好像您没有任何奇特的逻辑-您应该能够直接绑定到现有对象的属性，甚至不需要添加一个viewmodel层。