Silverlight Databinding – The Observable Collection

If you’re coming from the ASP.Net world and you want to start building silverlight controls, databinding is one those things that works somewhat the same, yet somewhat differently from the standard DataSource, DataBind() world that you may be used to.

For one thing, databinding in ASP.Net is done in a stateless way – once that binding operation is completed, it’s a done deal and if you want to change anything, now you have to manipulate the underlying controls that were created as a result of the data binding, or else change the underlying data objects and call DataBind() again.

That’s what we are used to – but it’s certainly not ideal. Enter Silverlight and the ObservableCollection<T>. This is a generic list type that allows you to put any object into it. This list implements INotifyCollectionChanged, such that it specifies and event that automatically notifys an underlying container when anything in the list has changed.

So that’s step 1 – use the ObservableCollection for you business object collection. Take note that by default, a WCF service proxy class in Silverlight will use this type of collection by default.

Then, in your actual data object classes, you need to implement the INotifyPropertyChanged on your data objects – this will allow you to raise the PropertyChanged event whenever the state of you object changes to the point where you want to notify the underlying collection or container that the state has changed.

Remember too, that this stuff isn’t really “Silverlight” specific – it was originally designed for databinding in Xaml for WPF, but since Silverlight using Xaml and a subset of WPF, this is really just following along the same paradigm.

What does all this really mean?

It means that once you have set up your data collections and underlying types, you can now follow the normal databinding rules, but once you change the underlying data objects themselves, either by modifying the collection or a property of an item in the collection, then the UI object will be updated too. This will only happen when the BindingMode is done using OneWay (the default), or TwoWay. The OneTime binding mode ignores any changes to the underlying collections so you can safely change them later without worrying about your UI going all wonky (or which thread you are operating from).

Threading will become very important when you are updating in item in an ObservableCollection – you need to be aware of what thread you are currently running in and possible use the Dispatcher to make that change – since the Notifier events will bubble up to the UI synchronously from the call you are in. Luckily we can trigger the dispatch from an anonymous delegate, so we don’t need to make extraneous methods for these any more.

So that’s the basics of the underpinnings of data binding in Silverlight (and thus, in Xaml). I like that it follows a similar front-end markup/code behind model to ASP.Net, but allows us to take advantage of a stateful environment – especially for calling web service and REST APIs asynchronously.

More later – joel.