Difference between ObservableCollection and BindingList

I want to know the difference between ObservableCollection and BindingList because I've used both to notify for any add/delete change in Source, but I actually do not know when to prefer one over the other.

Why would I choose one of the following over the other?

ObservableCollection<Employee> lstEmp = new ObservableCollection<Employee>();

or

BindingList<Employee> lstEmp = new BindingList<Employee>();

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.

Both have advantages and drawbacks that take some time to discover.

I had some trouble with BindingList because the change notification event occurs only after an item has been removed and provides only an index (which means that you have to keep track of which object was at which location if you have implement some post-removal mechanism). ObservableCollection, on the other hand, gives you a list of the removed items.

BindingList has a handy AddNew() method that allows a derived class to implement a factory pattern, e.g. to initialize the new items with values depending on the parent collection (for instance, a foreign key to the parent if the collection contains child items).

Note also that it is very easy to get a BindingList from an ObservableCollection, using (ToBindingList extension in Entity Framework), and that the returned (derived) BindingList implements features, like sorting, that lack in the plain vanilla one.