Data Bindings : Notification Mechanisms

Connecting two visual elements with a data binding is certainly convenient, but the most powerful data bindings involve a target that is a visual element but a source that is not, and which instead is probably something commonly referred to as a business object.

And now a warning is required:

Sometimes when programmers learn a new and important feature of an operating system —they feel a need to use that feature everywhere, perhaps just to try it out and give it some exercise. With dependency properties, this is not such a good idea. Certainly you should use dependency properties when you’re deriving from classes that already derive from DependencyObject, but you probably shouldn’t derive from DependencyObject for the sole purpose of using dependency properties.

In other words: Don’t start rewriting your business objects to use dependency properties!

Targets of data bindings must be dependency properties, but that is not a requirement for binding sources. Binding sources can be just regular old properties on regular old classes. However, if the source is changing, and you want the target updated with the current value of the source, the source must implement some kind of notification mechanism.

Almost always, business objects that serve as binding sources should implement the notification mechanism known as the INotifyPropertyChanged interface.

INotifyPropertyChanged is defined in the System.ComponentModel namespace—a clear indication that it transcends Silverlight and plays a very important role in .NET. This is how business objects provide notification that data has changed in some way.

INotifyPropertyChanged is also extremely simple, being defined like this:

public interface INotifyPropertyChanged
{
    event PropertyChangedEventHandler PropertyChanged:
}

A class can implement INotifyPropertyChanged simply by having a public event named PropertyChanged. In theory, the class needn’t actually do anything with this event, but proper decorum mandates that the class fires this event whenever one of its properties changes.

The PropertyChangedEventHandler delegate is associated with a PropertyChangedEventArgs class that has a single public get-only property named PropertyNamePropertyChangedEventArgs constructor. of type string. You pass the name of the property that’s changed to the

Sometimes a class that implements INotifyPropertyChanged will have a protected virtual method named OnPropertyChanged with an argument of type PropertyChangedEventArgs. This isn’t required but it’s convenient for derivative classes. I do this in my examples because the method is a convenient place to fire the event.

Because business objects that implement INotifyPropertyChanged do not derive from FrameworkElement, they do not form part of the visual tree in a XAML file; usually they’ll be instantiated as XAML resources or in the code-behind file.