dhopton's comment got me thinking. What are some situations where you wouldn't want to use an ObservableCollection?
+2
A:
When you want to have greater control over the notifications being sent by ObservableCollection. Example: The default implementation, while it supports adding ranges of elements, just throws a reset (I believe) for the whole collection rather than piece meal throwing out a single notification with all the new items on it. Part of this is because the default CollectionView in WPF doesn't support INotifyCollectionChanged notifications with Sizes > 1 (it throws if you do), so theres not much motivation for it to. However, if you are using a 3rd party grid, such as Xceed, it has a CollectionView derivation that does support arbitrary notification sizes. This means when you're bundling data into a list, you can get some pretty nice performance bumps by having the notifications grouped up.
Note that there are some interesting inflection points related to notification size, and priority of notifications that impact perceived performance, and actual performance (both not how you'd think).
It's a primary example of why you want your interface to be loose: We type as IList, and changed our implementation to our own, async-loading collection that fires collection changed events as we load chunks of data. View doesn't have to know about this difference. It just works.
dhopton
2010-01-24 05:34:29