Modern .NET data binding basics, part 1

Since Windows 8 is adopting Metro and XAML, it's a good time for developers to learn the basics about data binding.

When I first started Windows Phone 7 development, I did not have any real Silverlight or WPF experience. I understood the ideas underneath the data binding, but I never dug terribly deep with it. I kind of knew the magic incantations to chant in order to get data on the screen, but I kept resisting the data binding out of habit and ignorance more than anything else. After a certain point, it became clear that this was the right way forward, even though it was so different from the way WinForms did things. Because Windows 8 is adopting Metro and XAML, now is a good time to learn the basics if you have not already.

One of the cornerstones of the XAML data binding is the idea of notifications when the data changes. Unlike ASP.NET's clunky data binding, this data binding model is smooth and fluid once the links have been established; updating data lets the bound object know that the data has changed so they can take the needed actions, and the bound objects can update the underlying data if desired.

At the heart of this is the INotifyPropertyChanged and INotifyCollectionChanged interfaces. The first interface is used by objects to notify their consumers that individual properties (or even all properties) have changed. By handling the PropertyChanged event, the consumer receives the property name and can decide what to do from there. INotifyCollectionChanged is a bit more complex, but the idea is the same. Its added complexity comes from the different options to let the listener know what has been added, changed, or removed from the collection.

The good news is that you do not need to deal with that complexity in most cases. The ObservableCollection<T> class is a generic class that already implements INotifyCollectionChanged. From the perspective of using it, ObservableCollection<T> functions like List<T>, but when you add, replace, and remove items from the class, it fires the CollectionChanged event. Having this class available sure beats implementing this functionality yourself!

You will still need to implement INotifyPropertyChanged as needed on your business objects if you want to have the UI respond when you change their details, but for handling the typical "big list of data shown on the screen" scenario, ObservableCollection<T> is just what you need.

In an upcoming column, I will look at how two-way binding works to get the user's changes back to your business objects.




Justin James is the Lead Architect for Conigent.

Editor's Picks

Free Newsletters, In your Inbox