I just noticed something new in the MSDN documentation about the ObservableCollection<T>:
You can enumerate over any collection that implements the IEnumerable interface, and this is adequate for one-time data binding in Silverlight. However, to set up dynamic bindings so that insertions or deletions in the collection can update the UI automatically, the collection must implement the INotifyCollectionChanged interface. This interface exposes the CollectionChanged event, an event that should be raised whenever the underlying collection changes.
Silverlight provides the ObservableCollection<T> class, which is a provided base class data collection that implements the INotifyCollectionChanged interface, as well as the INotifyPropertyChanged interface. It also has the expected collection support, defined by deriving from the Collection<T> class.
That last part about Silverlight adding the INotifyPropertyChanged is pretty important. Previous versions of the MSDN and books about WPF mentioned that the ObservableCollection in fact did raise the PropertyChanged event but I soon found out it didn’t (and still doesn’t).
Now Silverlight adds this behavior. At first glance that is a good thing but thinking about it made me wonder: we now have a class (generic) in WPF/NET 3.5 and Silverlight with the same name and role but different behavior. That might prove to be a bad thing.
Let’s hope WPF/Net 3.5 will quickly follow the Silverlight.