The main new feature in the version 2.8.1 is support for building a hierarchy of tables linked with DataRelation.

We hope that you will appreciate grid quality, performance and convenience of interface. Let’s create feature-rich high-performance applications together.

Sincererly Yours,

Dapfor

It’s worth mentioning that handler of INotifyPropertyChanged notification is very poorly implemented. Low performance reflection is used for searching PropertyDescriptor and internal cache is very poorly organized thus significantly reducing performance. Specifically when the BindingList<T> receives notifications of new object, it compares this object with the previous object that was used for notification. If they are not identical, the binding list does a terrible thing – it runs through all objects to get the index of the notifying object. This seriously impacts performance when there are a lot of elements. When the number of elements is about 100 000, handling of a single notification takes about 1 ms, which is unacceptable for most applications.

In actual applications ListChangedType.ItemChanged event with ListChangedType.ItemChanged flag and set PropertyDescriptor is handled quite rarely. However, it is hard to disable INotifyPropertyChanged handling in a BindingList<T> via simple means. The only acceptable method of disabling handling is to use reflection. The thing is that the binding list in its constructor checks whether the data type implements INotifyPropertyChanged interface and sets raiseItemChangedEvents private variable to true if it does. Otherwise it is set to false. This variable influences only subscriptions to INotifyPropertyChanged interface. There is no direct access to this variable and it can be modified only via reflection. An example of code for this is provided below.

class CustomBindingList<T> : BindingList<T>
{
    public CustomBindingList()
    {
        FieldInfo fi = typeof (BindingList<T>).GetField("raiseItemChangedEvents",
                               BindingFlags.Instance | BindingFlags.NonPublic);
        if (fi != null)
        {
            fi.SetValue(this, false);
        }
    }
}

The above implements fully functional binding list with disabled handling of INotifуPropertyChanged interface events. At the same time the binding list notifies subscribers of adding or removing data just like in standard implementation of this container.

Some figures: In standard binding list implementation handling of 1000 notifications in 100 000 container took more than 600 msec. In optimized version this time – 0 since the container no longer subscribes to data objects. Besides that, no subscription enables memory saving.

This article concerns only binding list performance aspects. Another important aspect of working with binding lists INotifyPropertyChanged is their use in advanced binding.

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.

In our opinion, IBindingList should not contain hierarchy information. It is possible to use multiple binding lists to build it. For example, let’s take Strategy class that may contain multiple orders that can be dynamically added to this class or removed from it.

class Order
{
   ...
}

public class Strategy
{
    private readonly BindingList<Order> _orders = new BindingList<Order&gt();

    public IList<Order> Orders
    {
        get { return _orders; }
    }
}

//Add a new order to a strategy:
Order order = ...;
strategy.Orders.Add(order);

//Add a strategy to a grid
Strategy strategy = ...
grid.Rows.Add(strategy);

Let’s note that when a strategy is added to the grid, it cannot display orders as it doesn’t have hierarchy information. It is possible to use declarative binding to tell the grid that Strategy.Orders field should be viewed as hierarchy foundation.

public class Strategy
{
    [HierarchicalField]
    public IList<Order> Orders
    {
        ...
    }
}

When a strategy is added to the grid, it automatically subscribes to binding list returned by this strategy. It enables to use full-featured hierarchical binding with dynamic hierarchy modification without direct access to data presentation layer. To ensure complete separation of presentation layer from data layer we shall place strategy objects to IBindingList:

BindingList<Strategy> strategies = new BindingList<Strategy>();
//Populate collection with strategies
...

//Bind collection to the grid
grid.DataSource = strategies;

----- Strategies and orders will be presented in .Net Grid as following ---------------
+ Strategy
 |- Order
 |- Order
 | ...
+ Strategy
 |- Order
 |- Order
 | ...

Conclusion:
In our example we have achieved full separation of data from presentation. Data manipulation doesn’t require access to control, and this is true for hierarchical declarative data binding as well. Let’s also note that displayed data can be grouped, sorted and filtered without additional effort of the programmer.

In our opinion, the above hierarchy building method is one of the most efficient methods provided by the grid. Besides declarative binding, it is possible to build a hierarchy by simply adding data objects to any row. It is also possible to use conditional binding and binding on any hierarchy level.

Programmers working with actual applications know how much code is required to complete a seemingly simple task of representing hierarchy data in the grid and synchronize it with grid presentation (adding and removing rows, etc). They will definitely appreciate our efforts in this field.

For more information of declarative data binding click here.