Change notification in WPF is the mechanism by which you proprogate changes to your objects to whomever is listening for those changes.
One typical usage is in a data binding scenario, where the recipient is listening for changes to the objects being bound to in order to update the user interface.
One of the first burning issues in WPF is which way should you go when you need to implement change notification, as you have two choices:
1.Implement the INotifyPropertyChanged in your business objects, and for each property set raise the PropertyChanged event for that property. This notifies the data binding mechanism of WPF that a change has occurred.
2. Create each and every property as a dependency property. This provides the data binding mechanism of WPF with all the details required to keep itself in sync with the data. This means that you don’t need to implement the INotifyPropertyChanged interface and you don’t need to raise the PropertyChanged event either.
How do you choose?
Binding speed – version 2 is slightly faster in most line of business applications
Coding speed – version 2 is slower, due to the need for creating a dependency property – but there are snippets lurking around on the web which will create the basic skeleton for you
Flexibility – version 2 allows you to have bindings both ways in WPF, which can be useful sometimes. By that i mean you can use BindingMode to be OneWayToSource
Backward compatibility – version 1 can be used in winforms as INotifyPropertyChanged is a v2.0 interface
So what do I do?
I tend to use version 1 unless I need that extra 5-10% of speed or I need to be able to reverse the bindings by using BindingMode = OneWayToSource