我应该使用 WPF 数据绑定吗？
我有一个 WPF 应用程序，它将十多个 xml 配置文件的编辑封装在一个位置，这样部署工程师就不必知道哪些地方可能会发生变化，也可能不会发生变化。目前，每个配置都表示为自己的对象，并具有将各种 UI 项目更新为标准 get 和 set 函数的逻辑。
另一项功能是应用程序应读取这些配置文件的旧版本，并将任何更改的值复制到新安装中。非常简单，因为我们使用每个文件的对象表示。
我一直在研究 WPF 数据绑定，虽然它看起来非常适合读取和写入 XML 并在各种应用程序控件上显示，但我无法弄清楚如何实现复制部分。使用数据绑定是否会走上错误的道路？
I have a WPF application that encapsulates the editing of a dozen or so xml config files in a single place so that a deployment engineer does not have to know where things may or may not be changed. At the moment each config is represented as its own object with the logic to update various UI items as standard get and set functions.
One other feature is that the application should read in an older version of these config files and copy any changed values to a new installation. Really easy since we're using object representations of each file.
I've been looking at WPF databinding and while it looks great for reading and writing XML and displaying on the various application controls, I'm having trouble figuring out just how I would implement the copying part. Would I be heading down a wrong path by using Databinding at all?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“我应该在 WPF 中使用数据绑定吗？”问题的答案几乎总是“是”。真正的问题更多的是“我应该使用 WPF 数据绑定做什么？”
听起来您的应用程序的体系结构当前如下：
在 WPF 中，您将希望使用数据绑定将对象模型连接到 UI 控件。当前对象模型中复制 XML 文件并更新其内容等的所有功能，就 WPF 而言，所有这些都发生在另一个宇宙中。
如果当前在对象模型中实现的方法对需要推送到 UI 的对象属性进行了更改，则事情可能会变得更加复杂。例如，您可能会发现想要创建
Command对象以将这些方法公开给 UI，然后需要实现某种机制来在方法更改后引发PropertyChanged事件对象的属性。根据应用程序的整体架构，您可能不希望集成 WPF 对象（例如命令）或在对象模型中实现属性更改通知。这让您进入了 MVVM 模式（Joe White 提到的“视图模型层”）的领域，这是一种封装命令和属性更改通知（以及 WPF UI 需要的其他内容）的方法，而无需修改底层对象模型。没关系。第一次这样做时会有点不知所措，主要是因为当您开始研究时会发现的信息会向您展示您可能没有（或可能还没有）的问题的解决方案。但实际上，情况并没有那么糟糕。
The answer to the question, "Should I use data binding in WPF?" is almost invariably "Yes." The real question is more along the lines, "What should I use WPF data binding for?"
It sounds as though the architecture of your application is currently:
In WPF, you'll want to use data binding to connect the object model to the UI controls. All of the functionality in your current object model that copies XML files around and updates their contents and so on, all of that happens in another universe, as far as WPF is concerned.
If the methods currently implemented in your object model make changes to the objects' properties that need to be pushed out to the UI, things may get a little more complicated. For instance, you may find that you want to create
Commandobjects to expose these methods to the UI, and then need to implement some mechanism for raisingPropertyChangedevents after the methods change the objects' properties. Depending on the overall architecture of your application, you may not want to integrate WPF objects (e.g. commands) or implement property-change notification in your object model.That gets you into the territory of the MVVM pattern (the "viewmodel layer" that Joe White alludes to), which is a way of encapsulating commands and property-change notification (and other stuff that a WPF UI needs) without having to modify the underlying object model. That's OK. It's a little overwhelming the first time you do it, mostly because the information you'll find when you start researching it will show you solutions to problems that you may not have (or may not have yet). But really it's not so bad.
WPF 非常面向数据绑定，因此一般情况下使用数据绑定可能不会出错。
但是，您似乎专门询问了关于 XML 的数据绑定。而且我不明白你为什么要这样做。您已经拥有可以读取 XML 并将其写入配置文件的对象。不要通过添加以不同方式执行完全相同加载的绑定表达式来重复这些知识。特别是如果您的配置文件格式定期更改，您不想维护多个读取和写入它的代码副本。
只需将您的 UI 绑定到您已有的对象即可。如果它们足够简单，您正在考虑绑定到 XML，那么听起来您没有任何花哨的逻辑——您应该能够直接绑定到现有对象的属性，甚至不需要添加viewmodel 层。
WPF is very databinding-oriented, so you probably won't go wrong by using databinding in general.
However, you seem to be specifically asking about databinding to XML. And I don't see why you would want to do that. You already have objects that read and write your XML to your config files. Don't duplicate that knowledge by adding binding expressions that do the exact same loading in a different way. Especially if your config file format changes periodically, you do not want to maintain more than one copy of the code that reads and writes it.
Just bind your UI to the objects you already have. If they're simple enough that you were thinking about binding to the XML, then it doesn't sound like you have any fancy logic -- you should be able to bind directly to properties on your existing objects, without even needing to add a viewmodel layer.