Windows Forms Data Architecture

Summary

• Introduction to Data Binding in Windows Forms
• Data Providers
• Data Consumers
• Navigating data in windows forms
• Interfaces Related to Data Binding

Introduction to Data Binding in Windows Forms

Data binding is the process by which a data structure can be attached to a .NET Windows Forms component. Data binding allows you to display and make changes to data from within a Windows Forms component. You can bind Forms controls not just to traditional data sources like a DataSet and DataTable, but also almost to any data structure that contains data. In general, it is not important how data got into the structure. Therefore, you can bind to data that is read from the database, calculated at run time, or read from a file and so on.

With the .NET Framework you have the ability to bind any property on the control to some form of data source. For example:

• The background color of all controls could be bound to a column value from a DataTable. The DataTable would have been initialized from the data base.
• The size and font of all buttons could be bound to a variable that was initialized from a configuration file.
• and so on...

Types of Data Binding

Windows forms offers two types of data binding - simple binding and complex binding:

• Simple Binding
  This is the ability to bind a property on a control (say the BackColor on all System.Windows.Forms.Button objects on a form) to a single data element such as a variable or the value of a single column in a DataTable. Single-binding controls therefore, show only a single data element
  
• Complex Binding
  This is the ability to bind the control to more than one data element, typically more than one record in a database. For example, a ListBox is not bound to a single value but to multiple values. These values could come from the first column in a DataTable. Whereas a DataGrid can bind to multiple rows and values with these rows and values coming from a DataTable.

Note: Just as you can bind properties of controls to a data source (whether simple- or complex- binding),  you can also bind properties of controls to other properties.

Data-binding is used in almost all applications. Example include:

• Reporting.
• Master-Detail Relationship.
• Data Entry.
• Lookup tables.

Data Providers

Assuming some certain minimum requirements, data binding in Windows Forms allows you to bind the control to any data source ranging from a database to data in arrays and collections. As a minimum, a bindable data structure must support the IList interface. See Interfaces Related to Data Binding for more information on required interfaces.

The following list of items shows the types of structures and data containers that you can bind to:

• Arrays/Collections
  To act as a bindable data source, the data source must implement at least the IList interface. Some of the .NET classes that implement IList are Array, ArrayList and many others.
  
• ADO.NET Data Objects
  ADO.NET provides a number of bindable data structures as shown below:
  
  • DataColumn
    This is the building block of a DataTable. You can simple-bind a control to a DataColumn within a DataTable.
    
  • DataTable
    A DataTable represents a table with columns and rows. You can complex-bind a control to a DataTable to show its contents. However, note that when you bind to a DataTable you are really binding to the default view of that table.
    
  • DataView
    A DataView object is a customized view of data in a DataTable. You can simple- or complex-bind to the data in a DataView, but be aware that you are binding to snapshot of the data, rather than a clean updating data source.
    
  • DataSet
    A DataSet can be thought of as a collection of tables and the relations between these tables. You can simple- or complex-bind to the data in a DataSet, but be aware that you are binding to the DataSet's default DataViewManager.
    
  • DataViewManager
    A DataViewManager is a customized view of the entire DataSet, analogous to a DataView but with relations include.

Data Consumers

It is easier to understand the architecture of Windows Forms data binding from the provider side rather than from the consumer side. Note the following points:

• Any data provider that is bound to a Windows Forms control will automatically have with it an associated CurrencyManager object. 
• A CurrencyManager object keeps track of the data position within its associated data provider and supervises bindings to it.
• There will be a CurrencyManager object on a Windows Forms for each discrete data provider that is bound to control. For example, if several TextBox controls on a form are all bound to the same data provider, then all those TextBox controls will share the same CurrencyManager object. However, if multiple controls each bind to a different data provider, then there will be multiple CurrencyManager objects.
• Every Windows Forms will be automatically assigned a BindingContext object. The BindingContext object keeps track of all CurrencyManager objects on the form. Therefore any Windows Forms with data-bound controls will have at least one BindingContext object keeping track of one or more CurrencyManager objects which in turn keep track of one data provider.
• A Windows Forms with data-bound controls can contain more than one BindingContext object. For example, a Windows Forms may contain within it a container such a panel, group box, or a tab control. So if the tab control contains data-bound controls, then you can create a BindingContext object just for the tab control.

Below is a diagram that summarizes most of the above information:

For example, it is very common to bind a DataTable within a DataSet to .NET DataGrid - (via DataSource and DataMember properties at design-time and via SetDataBinding method at run time. When uses make changes to the grid, changes are automatically saved in the data source (DataTable in this case) - it is Windows Forms Data Binding architecture that writes the values of data-bound controls to the data rows they are bound to.

CurrencyManager Class

The CurrenyManager class keeps track of data position within its associated data provider, and as such is used to keep data-bound controls synchronized with each other (showing data from the same record). In .NET, data sources such as DataTable and DataView do not maintain a notion of a control's position within the data contained. Contrast this to ADO where the Recordset maintained a current record and provided methods to navigate to other records (MoveFirst, MoveNext, etc.) While .NET data sources no longer know where the current record is due to the absence of a cursor, multiple positions can be set on the data source

Currency within CurrencyManager is used to refer to the currentness of a position with the data structure. Therefore, an important property on the CurrencyManager is the Position property. The Position property can be used to determine the currency of all controls bound to the same CurrencyManager. For example, assume a DataTable has two columns called FirstName and LastName. Two TextBoxes are bound to the same collection; TextBox 1 is bound to FirstName and TextBox 2 is bound to LastName. When the Position property of the CurrencyManager is set to the n^th position, both text boxes will display the appropriate first and last names because they both point to the n^th position (but each is bound to a different column).

BindingContext Class

Each Windows Forms has at least one BindingContext object associated with it to manage one or more CurrnecyManager objects. For each data source, there is a single CurrnecyManager, and because a Windows Forms may have many controls with each control possibly bound to a different data source, there will be multiple CurrnecyManager objects. The purpose of the BindingContext is to manage these CurrnecyManager objects and allow you to retrieve any one of them.

For example, if you add a TextBox control to a form and bind it to a column within a DataTable (i.e., the data source), the TextBox will communicate with the BindingContext associated with that form. The BindingContext in turn talks to the specific CurrencyManager object for that data association. In the example below, two TextBoxes are bound to the same collection; TextBox 1 is bound to FirstName and TextBox 2 is bound to LastName columns within the Customers table in a DataSet.

txtFirstName.DataBindings.Add( "Text", dataset1, "Customers.FirstName" );
txtLastName.DataBindings.Add( "Text", dataset1, "Customers.LastName" );

The Control.DataBindings property allows you to retrieve the ControlBindingsCollection, which is the collection of data bindings to a contorl, in order to add a new Binding object to the collection. Control.DataBindings property is used to create Simple Binding.

Note: It is important to be consistent about how a control is bound to a data source. Otherwise, the BindingContext will create multiple CurrencyManager objects resulting in erroneous results. The following code shows two ways to set a data binding. Make sure you are consistent in your code - choose one method and stick with it:

ComboxBox1.DataSource    = dataSet1;
ComboxBox1.DisplayMember = "Customers.FirstName";
this.BindingContext[dataSet1, "Customers"].Position = 1;

ComboxBox1.DataSource    = dataSet1.Customers;
ComboxBox1.DisplayMember = "FirstName";
this.BindingContext[dataSet1.Customers].Position = 1;

Navigating data in windows forms

Controls that are bound to data sources use BindingContext and CurrencyManager objects to navigate through associated data. The following example shows how a handler to a button is used to increment the data position for a specific data binding. This will cause some GUI control (possible a data grid or combo box) to show the next data item(s). Note that setting the Position property beyond the first or last element will not generate an error. To ensure that you remain within the bounds of the collection, include login to test whether you will exceed the data element count:

private void btnNextData_Click( object oSender, System.EventArgs e )
{
    // Get current position and count of elements
    int nPos   = this.BindingContext[dataSet1, "authors"].Position;
    int nCount = this.BindingContext[dataSet1, "authors"].Count;

    // Ensure that we can advance to the next item
    if ( nPos < nCount - 1 )
        this.BindingContext[dataSet1, "authors"].Position += 1;
}

The CurrencyManager's object PositionChanged event can be used to determine whether the proposed Position value has exceeded the actual data element count. 

Interfaces Related to Data Binding

ADO.NET provides existing data structures (DataTable, etc. ) that support binding to .NET controls. However, the .NET Framework also allows you to create your own data structure classes to support data-binding at different levels of complexity - from basic data-binding to providing design-time support, error checking, and even structured rollback of changes made to data itself. 

The following list of interfaces are arranged from least complex to most complex in terms of data-binding support:

• IList
  IList interface is used to implement a collection of objects that can be individually accessed by index. In other words, IList is the base interface for all lists. Array and ArrayList classes (among others)  inherit from IList. The list must be homogenous, that is, it can only contains objects of a similar type because the first item of the index is what determines the collection's type. An IList-derived class would only be available for binding at run-time. 
  
• IList and IComponent
  By implementing both of these interfaces, data will be available for binding at both design-time and run-time.
  
• IBindingList
  An IBindingList-based collection class provides much more complex data-binding support than any of the other two interfaces. An IBindingList-based implementation offers change notification both when the list itself has changed (number of items in the list increases/descreases), as well as when the list items themselves change (for example, values are changed.)
  
  Change notification is enabled for an IBindingList-based collection class  by setting the SupportsChangeNotification property to true. This will cause the ListChanged event to fire whenever the list changes or an item in the list changes. Note that objects contained within the list must notify the list when they change so that the list can raise the ListChanged event.
  
• IEditableObject
  An IEditableObject-based collection class allows an object acting as a data source to control when changes to that object are made permanent. In other words, it provides functionality to commit or rollback changes to an object used as a data source. If the IEditableInterface is not implemented, then changes to the object acting as a data source cannot be rolled back
  
  This ability to commit/rollback changes to an object acting as a data source is implemented by way of implementing IEditableInterface methods - BeginEdit, EndEdit, and CancelEdit:
  
  • BeginEdit
    Signals the start of an edit on an object acting as a data source. An IEditableObject-based collection class must store all updates to the data source after calling BeginEdit in such a way that they can all be discarded after a call to CancelEdit. The implementation should also ignore further calls to BeginEdit, if BeginEdit has already been called. These subsequent calls to BeginEdit should not be destructive - subsequent BeginEdit calls cannot destroy the updates that have been made or change the data that was saved in the first BeginEdit call.
    
  • EndEdit
    Commits any changes since BeginEdit was called back to the object acting as a data source.
    
  • CancelEdit
    Discards any changes made to the data source.
    
• IDataErrorInterface
  Allows collection classes to offer custom error information that controls can bind to.