I have two reasons to eschew Windows Forms databinding. Complexity and Performance. As is usually the case, these two are related. You see, Microsoft designed databinding to accommodate a wide variety of controls, and an equally wide variety of datastructures. Because they couldn't predict exactly what we'd build, they designed a very flexible framework. But flexible often means complex, and slow, and in my opinion both are true here.

Controls and datastructures that are built into the .NET Framework typically "just work" when you bind them to each other. At least, that's been my experience. I think the same is true when you use controls that are supplied by any competent vendor. But if you try to create your own controls and datastructures and bind them together using Windows Forms databinding, you might find things get rather difficult.

As I've said before, don't use a tool if you don't understand what it does, and to fully understand Windows Forms databinding takes quite a bit of work.

Let's say you build a form and bind that to some complex datastructure of your own. First you have to understand databinding well enough to make it work as expected. Remember, you'll create the associations between controls on your form and data items in your datastructure, but the exact moment that values get copied backwards and forwards is not under your control. That single fact makes your code hard to maintain, in my opinion. Anyone trying to modify your form or your datastructure needs to fully understand databinding in order to know that it will continue to work as expected. And if at some point the binding isn't working as expected, someone will have to fully understand databinding in order to figure out where it's going wrong. Before you know it, everyone in the team has to understand databinding.

What's wrong with that? Well, surely to goodness the whole point of abstracting relationships between controls and data is to simplify. If everyone has to go and learn a somewhat complicated body of code in order to maintain your app, that simplification goal has gone awry.

Remember, Microsoft built databinding because they didn't know what types of controls, and what types of datastructure, we were going to create. To bind our controls to their data, or their controls to our data, we can use databinding. When we own the controls and the datastructures, we just don't need a flexible binding framework that can bind anything-to-anything. We can actually write obvious code that works intuitively to copy values from A to B. That might mean more lines of source code in our app, but it's a lot fewer lines of code being executed at runtime, and it's a lot more straightforward to maintain.

Ok, that's the complexity issue dealt with. I just want to say a little about performance. I accept that for most desktop apps Windows Forms databinding performs perfectly adequately. I happen to work on an app that's unusual in that, at times, it needs to update a lot of data on the screen very rapidly. I mean, much quicker than a human being can actually absorb. But we can't predict which value the user will want to look at, and when they look at it, it's got to be a very recent value. I mean, certainly no more than 100ms stale. If you know how Windows Forms databinding works, you'll know it doesn't lend itself to updating a lot of data that rapidly. This isn't a criticism of databinding, but it's worth knowing. I guess it wasn't designed to do this.

Because databinding towards the control is triggered from a property change in the underlying datastructure, any such change has to happen on the UI thread. You know you can't modify controls from some background thread. But when you're getting a lot of updates, you really need to minimize the work being done on your UI thread. I mean, it should really just be painting the screen and nothing else. I don't want to be managing my datastructure on the UI thread, rebuilding indexes and so forth. I want that to happen on another thread, then my UI thread can simply ask 10 times per second "what value should I draw here?". . And I certainly don't want to be creating objects to describe the property that just changed, simply to communicate that change to my control in a totally extensible and flexible way. I know what my datatypes are and I don't want to see source code that passes around property names as strings. That stuff just gives me the colliwobbles.

So there are two reasons why I'd rather not use Windows Forms databinding in my current project. The performance reason probably doesn't matter for most apps, and perhaps not for certain parts of my own app. The complexity reason on the other hand, well, that's the big one.