Difference between ObservableCollection and BindingList

Question

An ObservableCollection can be updated from UI exactly like any collection. The true difference is rather straightforward:

ObservableCollection<T> implements INotifyCollectionChanged which provides notification when the collection is changed (you guessed ^^) It allows the binding engine to update the UI when the ObservableCollection is updated.

However, BindingList<T> implements IBindingList.

IBindingList provides notification on collection changes, but not only that. It provides a whole bunch of functionality which can be used by the UI to provide a lot more things than only UI updates according to changes, like:

• Sorting
• Searching
• Add through factory (AddNew member function).
• Readonly list (CanEdit property)

All these functionalities are not available in ObservableCollection<T>

Another difference is that BindingList relays item change notifications when its items implement INotifyPropertyChanged. If an item raises a PropertyChanged event, the BindingList will receive it an raises a ListChangedEvent with ListChangedType.ItemChanged and OldIndex=NewIndex (if an item was replaced, OldIndex=-1). ObservableCollection doesn't relay item notifications.

Note that in Silverlight, BindingList is not available as an option: You can however use ObservableCollections and ICollectionView (and IPagedCollectionView if I remember well).

The practical difference is that BindingList is for WinForms, and ObservableCollection is for WPF.

From a WPF perspective, BindingList isnt properly supported, and you would never really use it in a WPF project unless you really had to.

The most important differences such as features and change notifications about the contained elements are already mentioned by the accepted answer but there are more, which also worth mentioning:

Performance

When AddNew is called, BindingList<T> searches for the added item by an IndexOf lookup. And if T implements INotifyPropertyChanged the index of a changed element is also searched by IndexOf (though there is no new lookup as long as the same item changes repeatedly). If you store thousands of elements in the collection, then ObservableCollection<T> (or a custom IBindingList implementation with O(1) lookup cost) can be more preferable.

Completeness

• The IBindingList interface is a huge one (maybe not the cleanest design) and allows the implementors to implement only a subset of its features. For example, the AllowNew, SupportsSorting and SupportsSearching properties tell whether AddNew, ApplySort and Find methods can be used, respectively. It often surprises people that BindingList<T> itself does not support sorting. Actually it provides some virtual methods letting the derived classes add the missing features. The DataView class is an example for a full IBindingList implementation; however, it is not for typed collections in the first place. And the BindingSource class in WinForms is a hybrid example: it supports sorting if it wraps another IBindingList implementation, which supports sorting.

• ObservableCollection<T> is already a complete implementation of the INotifyCollectionChanged interface (which has only a single event). It also has virtual members but ObservableCollection<T> is typically derived for the same reason as its base Collection<T> class: for customizing add/remove items (eg. in a data model collection) rather than adjusting binding features.

Copy vs. wrapping

Both ObservableCollection<T> and BindingList<T> have a constructor, which accepts an already existing list. Though they behave differently when they are instantiated by another collection:

• BindingList<T> acts as an observable wrapper for the provided list, and the changes performed on the BindingList<T> will be reflected on the underlying collection as well.
• ObservableCollection<T> on the other hand passes a new List<T> instance to the base Collection<T> constructor and copies the elements of the original collection into this new list. Of course, if T is a reference type changes on the elements will be visible from the original collection but the collection itself will not be updated.

One More big difference between ObservableCollection and BindingList that comes handy, and can be a bid decision factor on the topic :

BindingList List Change Handler:

ObservableCollection Collection change:

Brief of Above: If a property of an item is changed in BindingList, the ListChanged event will give you complete details of property(in PropertyDescriptor) and ObservableCollection won't give you that. In fact ObservableCollection will not raise change event for a property changed in an item.

Above conclusion are in regards of INotifyPropertyChanged implemented in model classes. By default none raises the changed event if a property is changed in an item.