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 ObservableCollection
s 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.
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.
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.