In what way is Databinding in WPF an improvement over past frameworks?

Question

What fundamentally changed in WPF databinding framework compared to past databinding frameworks?

I stress the term fundamentally that is to say the ARCHITECTURE not TECHNIQUES. Sure it brings improvement but I'm more interested in the evolutivity, maintenability and scalability and AGNOSTICISM (PORTABILITY) of such frameworks, that is I'm on the PARADIM level.

Why can't I see nowhere some UML schemas that really abstract the essences of WPF databinding compared to previous databinding frameworks to see if indeed it is just techniques or if it is a real PARADIGM improvement.

Answer 1

Coming from the Windows Forms world, these are the advantages of WPF data binding that I have found so far:

1. DataContext and binding Paths are specified separately, and a binding goes looking for its DataContext in a hierarchical fashion (with its parents) if it doesn't have one specified on itself.

   The advantage of this can be seen e.g. with ListViews and DataTemplates; the former might specify the data source (DataContext), while the latter defines how the source items' properties (specified via Path) will be displayed.

   (There is one possible problem with this, btw.: AFAIK, there's no way in XAML to make sure at compile-time that both DataContext and Path refer to an object of the same type.)

2. Paths can be more complex than simply the name of a property. This is probably most useful when binding to XML (you can specify an XPath expression to refer to data), rather than binding against POCOs.

3. WPF doesn't seem to have some of the annoying problems on Windows Forms data binding:

   • See my previous question Winforms data-binding to business objects in a multi-threaded scenario without InvokeRequired? — IIRC, it still takes some work getting updates from background threads right (via Dispatcher) even with WPF, but from what I've seen, things are better than with Winforms. I remember there being an example shown in Jason Dolinger's video on the MVVM pattern.
     
     (Edited: In this respect, things actually haven't changed all that much since Winforms. BeginInvoke has simply been replaced by the Dispatcher class, which makes things somewhat nicer on the surface, but fundamentally it's still the same mechanisms.)

   • Winforms data binding: Can a TypeConverter be used instead of the Format/Parse events? — value conversion done by a binding is more easy than with Winforms, because value converters can be specified directly in XAML; in Winforms, you can only do value conversion via the Format/Parse events which are defined on the binding itself; you cannot specify a value converter directly in the Windows Forms designer. Therefore you need to set up the binding in your code-behind; which means you need to refer to a UI control by name; which at least partly breaks separation of the View and the Presenter (if you're trying to work with the MVP pattern). Not nice.

4. Commands didn't exist in Winforms. Instead of commands, you had to work with events and event handlers in the code behind (e.g. saveButton_Clicked). Now, if you wanted to delegate all logic to a Presenter class (again, in an MVP setting), you would manually have to forward events such as a button click from your View to the Presenter. In WPF, data-binding is complemented by the availability of ICommand/RoutedCommand, which makes this process far easier.