Interfaces Related to Data Binding

With ADO.NET, you can create many different data structures to suit the binding needs of your application and the data you are working with. You may want to create your own classes that provide or consume data in Windows Forms. These objects can offer varying levels of functionality and complexity, from basic data binding, to providing design-time support, error checking, change notification, or even support for a structured rollback of the changes made to the data itself.

Consumers of Data-Binding Interfaces

Following sections describe two groups of interface objects. The first group lists interfaces that are implemented on data sources by data source authors. These interfaces are designed to be consumed by data source consumers, which are in most cases Windows Forms controls or components. The second group lists interfaces designed for use by component authors. Component authors use these interfaces when they are creating a component that supports data binding to be consumed by the Windows Forms data-binding engine. You can implement these interfaces within classes associated with your form to enable data binding; each case presents a class that implements an interface that enables interaction with data. Visual Studio rapid application development (RAD) data design experience tools already take advantage of this functionality.

For more information about implementing interfaces, see Implements Keyword and Implements Statement (Visual Basic) or interface (C# Reference) (C# keyword).

Interfaces for Implementation by Data Source Authors

The following interfaces are designed to be consumed by Windows Forms controls:

• IList interface

  A class that implements the IList interface could be an Array, ArrayList, or CollectionBase. These are indexed lists of items of type Object. These lists must contain homogenous types, because the first item of the index determines the type. IList would be available for binding only at run time.

  Note
  If you want to create a list of business objects for binding with Windows Forms, you should consider using the BindingList. The BindingList is an extensible class that implements the primary interfaces required for two-way Windows Forms data binding.

• IBindingList interface

  A class that implements the IBindingList interface provides a much higher level of data-binding functionality. This implementation offers you basic sorting capabilities and change notification, both for when the list items change (for example, the third item in a list of customers has a change to the Address field), as well as when the list itself changes (for example, the number of items in the list increases or decreases). Change notification is important if you plan to have multiple controls bound to the same data, and you want data changes made in one of the controls to propagate to the other bound controls.

  Note
  Change notification is enabled for the IBindingList interface through the SupportsChangeNotification property which, when true, raises a ListChanged event, indicating the list changed or an item in the list changed.

  The type of change is described by the ListChangedType property of the ListChangedEventArgs parameter. Hence, whenever the data model is updated, any dependent views, such as other controls bound to the same data source, will also be updated. However, objects contained within the list will have to notify the list when they change so that the list can raise the ListChanged event.

  Note
  The BindingList provides a generic implementation of the IBindingList interface.

• IBindingListView interface

  A class that implements the IBindingListView interface provides all the functionality of an implementation of IBindingList, as well as filtering and advanced sorting functionality. This implementation offers string-based filtering, and multicolumn sorting with property descriptor-direction pairs.

• IEditableObject interface

  A class that implements the IEditableObject interface allows an object to control when changes to that object are made permanent. This implementation affords you the BeginEdit, EndEdit, and CancelEdit methods, which enable you to roll back changes made to the object. Following is a brief explanation of the functioning of the BeginEdit, EndEdit, and CancelEdit methods and how they work in conjunction with one another to enable a possible rollback of changes made to the data:

  • The BeginEdit method signals the start of an edit on an object. An object that implements this interface will need to store any updates after the BeginEdit method call in such a way that the updates can be discarded if the CancelEdit method is called. In data binding Windows Forms, you can call BeginEdit multiple times within the scope of a single edit transaction (for example, BeginEdit, BeginEdit, EndEdit). Implementations of IEditableObject should keep track of whether BeginEdit has already been called and ignore subsequent calls to BeginEdit. Because this method can be called multiple times, it is important that subsequent calls to it are nondestructive; that is, subsequent BeginEdit calls cannot destroy the updates that have been made or change the data that was saved on the first BeginEdit call.

  • The EndEdit method pushes any changes since BeginEdit was called into the underlying object, if the object is currently in edit mode.

  • The CancelEdit method discards any changes made to the object.

  For more information about how the BeginEdit, EndEdit, and CancelEdit methods work, see Saving Data Overview.

  This transactional notion of data functionality is used by the DataGridView control.

• ICancelAddNew interface

  A class that implements the ICancelAddNew interface usually implements the IBindingList interface and allows you to roll back an addition made to the data source with the AddNew method. If your data source implements the IBindingList interface, you should also have it implement the ICancelAddNew interface.

• IDataErrorInfo interface

  A class that implements the IDataErrorInfo interface allows objects to offer custom error information to bound controls:

  • The Error property returns general error message text (for example, "An error has occurred").

  • The Item property returns a string with the specific error message from the column (for example, "The value in the State column is invalid").

• IEnumerable interface

  A class that implements the IEnumerable interface is typically consumed by ASP.NET. Windows Forms support for this interface is only available through the BindingSource component.

  Note
  The BindingSource component copies all IEnumerable items into a separate list for binding purposes.

• ITypedList interface

  A collections class that implements the ITypedList interface provides the ability to control the order and the set of properties exposed to the bound control.

  Note
  When you implement the GetItemProperties method, and the PropertyDescriptor array is not null, the last entry in the array will be the property descriptor that describes the list property that is another list of items.

• ICustomTypeDescriptor interface

  A class that implements the ICustomTypeDescriptor interface provides dynamic information about itself. This interface is similar to ITypedList but is used for objects rather than lists. This interface is used by DataRowView to project the schema of the underlying rows. A simple implementation of ICustomTypeDescriptor is provided by the CustomTypeDescriptor class.

  Note
  To support design-time binding to types that implement ICustomTypeDescriptor, the type must also implement IComponent and exist as an instance on the Form.

• IListSource interface

  A class that implements the IListSource interface enables list-based binding on non-list objects. The GetList method of IListSource is used to return a bindable list from an object that does not inherit from IList. IListSource is used by the DataSet class.

• IRaiseItemChangedEvents interface

  A class that implements the IRaiseItemChangedEvents interface is a bindable list that also implements the IBindingList interface. This interface is used to indicate if your type raises ListChanged events of type ItemChanged through its RaisesItemChangedEvents property.

  Note
  You should implement the IRaiseItemChangedEvents if your data source provides the property to list event conversion described previously and is interacting with the BindingSource component. Otherwise, the BindingSource will also perform property to list event conversion resulting in slower performance.

• ISupportInitialize interface

  A component that implements the ISupportInitialize interface takes advantages of batch optimizations for setting properties and initializing co-dependent properties. The ISupportInitialize contains two methods:

  • BeginInit signals that object initialization is starting.

  • EndInit signals that object initialization is finishing.

• ISupportInitializeNotification interface

  A component that implements the ISupportInitializeNotification interface also implements the ISupportInitialize interface. This interface allows you to notify other ISupportInitialize components that initialization is complete. The ISupportInitializeNotification interface contains two members:

  • IsInitialized returns a boolean value indicating whether the component is initialized.

  • Initialized occurs when EndInit is called.

• INotifyPropertyChanged interface

  A class that implements this interface is a type that raises an event when any of its property values change. This interface is designed to replace the pattern of having a change event for each property of a control. When used in a BindingList, a business object should implement the INotifyPropertyChanged interface and the BindingList`1 will convert PropertyChanged events to ListChanged events of type ItemChanged.

  Note
  For change notification to occur in a binding between a bound client and a data source your bound data-source type should either implement the INotifyPropertyChanged interface (preferred) or you can provide propertyNameChanged events for the bound type, but you shouldn't do both.

Interfaces for Implementation by Component Authors

The following interfaces are designed for consumption by the Windows Forms data-binding engine:

• IBindableComponent interface

  A class that implements this interface is a non-control component that supports data binding. This class returns the data bindings and binding context of the component through the DataBindings and BindingContext properties of this interface.

  Note
  If your component inherits from Control, you do not need to implement the IBindableComponent interface.

• ICurrencyManagerProvider interface

  A class that implements the ICurrencyManagerProvider interface is a component that provides its own CurrencyManager to manage the bindings associated with this particular component. Access to the custom CurrencyManager is provided by the CurrencyManager property.

  Note
  A class that inherits from Control manages bindings automatically through its BindingContext property, so cases in which you need to implement the ICurrencyManagerProvider are fairly rare.

See Also

Tasks

How to: Create a Simple-Bound Control on a Windows Form

Concepts

Data Binding and Windows Forms

Other Resources

Windows Forms Data Binding