views:

47

answers:

1

I'm in the process of learning WPF, where one of the strong suits is supposed to be data binding. When I do a win forms app, because I don't trust data binding much, I use what Fowler would call an assembler and just do it by hand, which makes it easy to test also.

I've read Jeremy Miller's blog enough to see he has issues with data binding too (even with wpf), and circumvents it, but I never did see a clear example of how he does it.

I do like what I see so far with wpf's rendering and layout capabilities, but I'm just not sure about the MS data binding technology. My question is does anyone have any reasons why data binding is so good in wpf you can easily separate concerns and test it, and if not, what is the basic idea you use as an alternative?

Cheers,
Berryl

+2  A: 

I don't want to speak for Jeremy, but I believe his beef with data binding is less about the binding itself, and more about how it results in hard to debug/test/maintain code. This is certainly true of WPF/SL when you include your bindings in XAML because they can break without you being aware of that until runtime (and maybe not even then). A nice fluent interface can make binding an absolute pleasure to write, debug, and maintain. It was one of my motivations for writing Truss.

However, doing your data binding in code can break the designer/developer collaboration. Blend doesn't execute code when designers open up a UserControl or whatever. Therefore, any bindings written as code will not be hooked up.

In an ideal world, we wouldn't be forced to choose between maintainability and designer collaboration. But that seems to be where things are at the moment.

HTH, Kent

Kent Boogaart
Wow, that was more than I expected - thx! The other part of Jeremy's beef (if I remember) has is about POCO noise pollution via property notifications. Looking forward to going through TRUSS though. Cheers
Berryl