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.


  • Hi Mr Varty,

    great articel. I love it to use observable collection but is there a way to use it in as well?
    It seems to me that this collection is only avaiable in WPF and Silverlight? Is there a similar collection for which works on the same way?

    thx in advance


    Tim Mischkin

  • Hey Tim - ajax 4 will be getting "live" bindings in the new client templating. Check it out:

  • Suppose you return UserCollection to the Silverlight client using WCF and the client puts it in a DataGrid.ItemSource. Now someone modifies a name in one of the FirstName cells.

    Now how do you get just that changed cell or row of that cell to go back to the middle tier? Or if you send the whole UserCollection back to the middle tier how can you tell what's changed in the collection?

    In my case, I created an [OperationContract] method in my wcf service called

    SaveChanges(ObservableCollection person)

    and in my Silverlight client I call


    When the WCF method receives the collection, I can see the modified name if I inspect each row however I have no idea how to programatically know that the name has been modified in any given row.

    Can you please explain that?

  • Just send the item that changed to the WCF service. Make a method that accepts the single Person object and persist that to the db.



  • Based on his response of "just persist that object to the database" he doesn't know either. Joel simply inserting a record in the db doesn't magically update the item in question magically.

  • Interesting. I have been searching forever on how to iterate thru my datagrid in silverlight 4 VB. Thanks

Comments have been disabled for this content.