List<T> vs BindingList<T> Advantages/DisAdvantages

Question

Can someone describe what the difference between the two are for my project.

Currently I have a List<MyClass> and set the BindingSource to that and a DataGridView to the BindingSource.

I have implemented IEditableObject so when CancelEdit is called I revert my object back to what it was with a Memberwise.Clone()

Will changing my List to a BindingList solve any of this and what are the advantages of using a BindingList?

Solution 1

A List<> is simply an automatically resizing array, of items of a given type, with a couple of helper functions (eg: sort). It's just the data, and you're likely to use it to run operations on a set of objects in your model.

A BindingList<> is a wrapper around a typed list or a collection, which implements the IBindingList interface. This is one of the standard interfaces that support two-way databinding. It works by implementing the ListChanged event, which is raised when you add, remove, or set items. Bound controls listen to this event in order to know when to refresh their display.

When you set a BindingSource's DataSource to a List<>, it internally creates a BindingList<> to wrap your list. You may want to pre-wrap your list with a BindingList<> yourself if you want to access it outside of the BindingSource, but otherwise it's just the same. You can also inherit from BindingList<> to implement special behavior when changing items.

IEditableObject is handled by the BindingSource. It'll call BeginEdit on any implementing object when you change the data in any bound control. You can then call EndEdit/CancelEdit on the BindingSource and it will pass it along to your object. Moving to a different row will call EndEdit as well.

Solution 2

A BindingList allows two-way databinding by using events, a List does not fire events when its collection changes.

I don't think it will fix your particular problem.

Comments

[Jon]

Currently with my List<T> approach calling CancelEdit will not return the item being edited back to its original state hence why I use Clone(). Are you saying a bindinglist will handle that for me?

[venkat]

No, a BindingList has nothing to do with that functionality. The BindingSource simply calls CancelEdit on the current object regardless of the type of underlying list. There's nothing in the framework that automatically implements object versioning for plain objects. You can use DataTables/DataRows, which keep an original copy of the data for just this purpose.

[Jon]

You say that controls need to know when the list changes, can you explain further? I have a form with a datagridview and then another form from that with populated data. Do I need to concern myself about what your saying in this matter?

[venkat]

For example, the DataGrid needs to know when items are added to your list in order to add a new row. For that it uses the ListChanged event of the BindingList. If you were binding the grid directly to a List<T>, you would not have the event, and the grid wouldn't be able to know when you changed the list. You don't have to worry about it in your scenario because the BindingSource wraps the List<T> in a BindingList for you. As long as you work with the BindingSource and not the list itself, the controls will stay in sync.

[Lance]

Is there any workaround to use BindingList to WPF UI (the mvvm way)? Can I wrap the bindinglist to an observablecollection?

[venkat]

@LawrenceA.Contreras: If you already have a BindingList, just bind to it directly. They are fine in your ViewModel! The functionality offered by BindingList is mostly a superset of ObservableCollection.

[Lance]

@Ilia Jerebtsov, I don't think BindingList has same functionality as observablecollection. I think bindinglist doesn't have a notification on collection changed. But I'm not sure though. stackoverflow.com/questions/4284663/…

[venkat]

@LawrenceA.Contreras: See IBindingList.ListChanged Event

[Lance]

Hmm can we use that in to bind with a xaml and work exactly like observable collection?