Does WPF databinding make things more of a pain than it is worth?

Question

Ok, So I have been stalled in my latest non-work project, trying to use WPF. I am just frankly annoyed at databinding. I thought it was supposed to make things simpler by binding data directly to the UI. But the more I learn about having to implement INotifyPropertyChanged to get things to notify the UI if they changed, seems to make the whole thing counter productive.

Am I missing something? It seems like a bunch of work and having to make the classes implemented INotifyPropertyChanged seems like a fishy way to get databinding to work.

What am I missing? I must be missing something. Please enlighten me into how to make databinding easy, or at the least straightforward.

Answer 1

If you want the UI be notified when the underlying data source changes, then you need some sort of notification mechanism. For WPF, INotifyPropertyChanged is that mechanism.

It's the same in Windows Forms as well, but Windows Forms also supports the old notification mechanism, where you have an event with the name <Property>Changed.

However, neither of these required these mechanisms if all you want to do is bind to the data once and display it.

If you are ok with not receiving notifications, then just bind to the data source and it will work.

Answer 2

Truth be told, I haven't seen that it was that bad, and think it a highly workable solution.

Take this simple, Data Model object:

Public Class SimpleItemViewModel
Implements INotifyPropertyChanged

Private _item As String 
Public Property Item As String
   Get 
       return _item 
   End Get 
   Set (value as string) 
      _item = value : OnPropertyChanged("Item") 
   End Set 
End Property 

Protected Overridable Sub OnPropertyChanged(propChange as string) 
   Raise Event PropertChanged(me, new PropertyChangedEventArgs(propChange))
End Sub 
Public Event PropertyChanged(sender as object, e as PropertyChangedEventArgs)
End Class

That is easily bound to a simple Textbox via:

<Textbox Text="{Binding Item}" />

additionally, if I wanted to have a DIRTY flag, I can easily put the flag being set in the OnPropertyChanged sub, and easily determine if I need to save any user changes or not.

I have found it easiest to have a set of classes which rest between the Data Access layer and the UI which holds this stuff. You can even have your Business Logic and DAL pass these classes around rather than the atomic values.

Answer 3

DataBinding is the only way to implement a model-view pattern in WPF/Silverlight. Your models can be UI-stupid by implementing INotifyPropertyChanged, which isolates them from the UI. It also saves a lot of UI code when stuffing information into the UI.

Another benefit that I enjoy is the ability to further bind child controls with the same data by using the { Binding } shortcut.

Answer 4

First, INotifyPropertyChanged isn't the only way to get data binding to work - dependency properties work too.

Second, INotifyPropertyChanged can be implemented with just one line of code in your entity class, if you use AOP - you don't actually have to do all those notification calls yourself.

Overall, I'd say data binding is a great boon, especially when you're doing code generation to make automatically bound controls from some data source.

Answer 5

Implementing INotifyProperty changed is not particularly difficult, seeing as it only has one member.

If you don't expect changes in the underlying object then don't worry about INotifyProperty changed, and use a Binding with Mode=OneTime.

If the underlying object can change and you want the GUI to reflect those changes, then how else can this be achieved without the kind of notification that INotifyProperty changed provides? It's not reasonable to expect a bound item to poll its binding's source.

Personally I've found WPF has taken some time to get to grips with, but now that I'm gaining comfort I'm finding it incredibly powerful and enjoyable to work with. I encourage anyone who's finding WPF challenging to stick with it.

Answer 6

If you're looking for a good way to think about structuring your data binding, then aim to set a DataContext on your logical tree only once, then use binding paths to populate the various parts of your UI.

Answer 7

Be as declarative as you can in your binding. Let the template system do it's job and make heavy use of DataTemplates that specify explicit DataTypes.

Answer 8

Binding in XAML is quite easy, however, dynamic WPF data binding in code is painful and confusing.