BindingList(T) is an implementation of IBindingList interface that notifies subscribers of changes in collection. Usual subscribers are grids, lists and other graphical controls that work with data collections. Such controls get notifications via IBindingList.ListChanged event. This event is fired when data is added to or removed from the collection and upon major changes of the collection. For this reason, ListChangedEventArgs specifies event that occurred at the collection and the grid rebuilds its internal data presentation structure basing on this information. There can be the following ListChangedType: ItemAdded, ItemChanged, ItemDeleted, ItemMoved, PropertyDescriptorAdded, PropertyDescriptorChanged, PropertyDescriptorDeleted, Reset. There are simple types – adding/removing and complete rebuilding of data. However, ItemChanged reason is very interesting. In this case instead of internal changes of the collection (adding, removing, etc) the binding list reports changes of data objects. For this purpose the binding list subscribes to each object implementingINotifyPropertyChanged interface by adding a handler to INotifyPropertyChanged.PropertyChanged event. By getting a notification from such object, the binding list doesn’t manipulate its internal data structure but transforms the received notification into its ownIBindingList.ListChanged event with ItemChanged value and PropertyDescriptor corresponding to the field of notifying object.

The following code can be used to get PropertyDescriptor from PropertyChangedEventArgs:

object dataObject = ...;
string propertyName = "someProperty";

PropertyDescriptor property = TypeDescriptor.GetProperties(dataObject)[propertyName];

Performance here is not very high, but it is not critical as there is a more serious issue. BindingList(T) contains internal cache that theoretically should improve performance. This cache compares objects that fired INotifyPropertyChanged notifications. When subsequent notifications are received from the same object, this cache works perfectly. However, when they are fired by different objects, the binding list tries to calculate a new index of object in the collection that has fired the notification. For this purpose the binding list callsIList.IndexOf(Object) triggering linear enumeration of all collection elements to find the required element's index. This means that upon every notification from objects implementing INotifyPropertyChanged, the binding list enumerates all objects in the collection.

The second serious issue of the binding list is that upon getting a notification from an object with non-existing property, the binding list generates IBindingList.ListChanged event with Reset cause making the grid to rebuild all its contents.

class MyDataObject : INotifyPropertyChanged
{
    private string _lastPrice;

    [Field("Price")]
    public string LastPrice
    {
        get { return _lastPrice; }
        set
        {
            if (_lastPrice != value)
            {
                _lastPrice = value;

                if (PropertyChanged != null)
                {
                    //This code will cause Reset in BindingList because MyDataObject doesn't contain "Price" property
                    PropertyChanged(this, new PropertyChangedEventArgs("Price"));
                }
            }
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

It is doubtful that binding list’s subscription to INotifyPropertyChanged is useful as it doesn’t process these notifications but only transforms them to IBindingList.ListChanged format. It doesn’t make any internal manipulations with its own data.

ThreadSafeBindingList(T) container is only a wrapper for BindingList(T) and fully replicates its functionality. When Dapfor’s developers discovered the cause for low performance, they blocked BindingList(T) subscription to INotifyPropertyChanged events solving two problems at once. The first problem was incorrect organization of internal cache, and the second problem was getting notifications from objects with non-existing properties. Still, ThreadSafeBindingList(T) doesn’t block firing notifications upon adding/removing items just as the standard container.

Architecture of the Wpf GridControl enables it to subscribe to events of objects implementing INotifyPropertyChanged interface without regard to the adding method. When the grid receives notifications from these objects, it performs thread synchronization, data update, sorting, regrouping, filtering and highlighting. Therefore, blocking BindingList(T) subscription to INotifyPropertyChanged interface doesn’t impact application functionality and significantly improves their performance.

BindingList(T) is not a thread-safe container. As said above, the main purpose of creating ThreadSafeBindingList(T) was to protect the binding list from competitive access by multiple application threads.

ThreadSafeBindingList(T) is just a wrapper that contains the BindingList(T) and locks its internal method. ThreadSafeBindingList(T) implementation prevents occupation of synchronizing object at the time when notification is fired. It is especially important to avoid potential deadlock problems when two synchronizing objects are taken by the opposite threads.

To summarize the above, Dapfor recommends using ThreadSafeBindingList(T) instead of standard BindingList(T). This ensures thread protection for the application and significantly improves application performance by optimizing usage of the standard container.