CODEWITHSUNDEEP
wpfxamldata-binding
Damien Ryan
Damien Ryan

Reputation: 1591

Should I use WPF databinding?

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?

Upvotes: 0

Views: 601

Answers (2)

Robert Rossney
Robert Rossney

Reputation: 96870

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:

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

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 Command objects to expose these methods to the UI, and then need to implement some mechanism for raising PropertyChanged events 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.

Upvotes: 1

Joe White
Joe White

Reputation: 97848

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.

Upvotes: 1

Related Questions