Binding list and thread safety

Posted on | February 13, 2012 | 1 Comment

Data binding is the basis of modern applications based on separation of data layer from presentation layer. The main purpose of such separation is to make application logic independent of its representation. Otherwise, logic code should not directly call presentation layer class methods (i.e. Control class methods). When internal state changes, business logic layer sends a GUI notification via IBindingList / INotifyPropertyChanged interfaces and the presentation layer displays modified data on screen.

It is necessary to note that there is a serious obstacle to implementing such event-driven model – thread safety. Business logic shouldn’t know anything of presentation, not only with regard to direct links to GUI classes but also with regard to thread used for subscriber notification. However, in actual applications things are more complicated. Application usually has a single GUI thread where the controls work. All control methods should be called only from this thread. However, data binding doesn’t consider this aspect, i.e. when a data source is connected, most controls imply that all notifications come from the main thread and don’t synchronize. This results in application crashes when notifications arrive from non-GUI thread.

While working with numerous real-world applications we have noted that developers often don’t follow the principle of separating data layer from the presentation layer because it is necessary to synchronize notifications with GUI thread. This means that synchronization is performed by business logic and not by the presentation layer. Thus, the required call of Control.Invoke/Control.BeginInvoke method is placed to business logic that should contain a reference to control that will process notifications. 

class FeedCollection : BindingList<Feed>
{
    private Control _control;

    //The method is called when data is updated (for ex. data comes from TCP/IP)
    void OnUpdateReceiced(...)
    {
        _control.Invoke(new MethodInvoker(delegate
        {
            //Raise notification in GUI thread
            OnListChanged(new ListChangedEventArgs(...));
        }));
    }
}

DataGrid someGrid = ...;
FeedCollection feed = ...;
someGrid.DataSource = feed;



It is only one of the examples where rules of separating logic from presentation are violated. When our developers were working on .Net Grid, they have initially designed its architecture to receive notifications from any thread and to perform thread synchronization after that. Thus, business logic can be fully separated from the presentation layer and safely notify subscribers without pre-synchronization of threads and therefore without unnecessary references to GUI controls. 

class FeedCollection : BindingList<Feed>
{
    //The method is called when data is updated (for ex. data comes from TCP/IP)
    void OnUpdateReceiced(...)
    {
        //Raise notification directly from non-GUI thread
        //Dapfor .Net Grid will synchronize threads itself.
        OnListChanged(new ListChangedEventArgs(...));
    }
}

Dapfor.Net.Ui.Grid grid = ...;
FeedCollection feed = ...;
grid.DataSource = feed;


As we have said above, ensuring thread safety is not a trivial task for application developers. Complex modern applications may contain a lot of assemblies. Some of them may contain codes with graphical controls, others may contain business logic, various math libraries, code for TCP/IP interaction, etc. However, limitations related to GUI operation only in one thread and thread synchronization method require unneeded and dangerous dependencies of business logic from graphical components (Control.Invoke/Control.BeginInvoke). This may seriously violate the principle of business logic independence from its presentation. Dapfor .Net Grid doesn’t just enable thread synchronization, but also makes it possible to completely avoid such dependencies using an event-driven model. It means that if the application is well architected, business logic assemblies will not (and should not!) depend on Dapfor assemblies and System.Windows.Forms libraries.

Category: Data binding, thread safety
Tags: > > >

Comments

One Response to “Binding list and thread safety”

  1. Why BindingList is slow with objects implementing INotifyPropertyChanged interface | Dapfor.Net Grid Blog
    March 29th, 2012 @ 18:59

    [...] This article concerns only binding list performance aspects. Another important aspect of working with binding lists and INotifyPropertyChanged interface is their use in Multi-Threaded applications. [...]

Leave a Reply