Interfaces Related to Data Binding
With ADO.NET, you can create a host of different data structures to suit the binding needs of your application and the data you are working with. For information on data binding in ADO.NET, see Introduction to Distributed Applications and Data Integration. It is also possible to create your own classes that provide data. These objects can offer varying levels of functionality and complexity, from basic data binding, to providing design-time support, error checking, or even support for a structured rollback of the changes made to the data itself.
Below is a progressive list of interface objects, from least complex to most, each offering more data-binding functionality than the previous object. 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's rapid application development (RAD) data design experience tools already take advantage of this functionality.
- IList interface
- A class that implements the IList interface could be an Array, an ArrayList, or a Collection. Any of these is an indexed list of items of type Object. This must be a list of homogenous types, because the first item of the index is what determines the type. This class would only be available for binding at run time.
- Typed IList interface
- This is an implementation of the IList interface that is typed (that is, not just objects, but objects of a certain kind, such as "Customers" in the classic business-database example). The Item property returns an item of the given type. A class that implements a typed IList interface is only available for binding at run time.
In the example below, the custom type is
' Visual Basic Dim cust as New Customers() // C# Customers cust = new Customers(); // C++ Customers* cust = new Customers();
- IList and IComponent interfaces implemented
- By implementing both of these interfaces, the data is available for binding at design time (it will appear in the component tray) and run time.
Note While the data providers enumerated thus far are aware of updates made to lists by the controls on the form, they do not take advantage of updates to items in the list made in code. Use an implementation of the IBindingList interface, described below, if you need such change notification.
- IBindingList interface
- A class that implements the IBindingList interface provides a much higher level of data-binding functionality. This implementation offers you change notification, both for when the list itself has changed (for example, the number of items in the list increases/decreases), as well as when the list items themselves change (for example, the third item in a list of customers has a change to the Address field).
Tip Change notification is enabled for the IBindingList interface through setting 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 ListChangeType parameter of the ListChanged event. Hence, whenever the data model is updated, any dependent views will also be updated. However, be aware that objects contained within the list will have to notify the list when they change so that the list can raise the ListChanged event.
- 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 allow you to roll back changes made to the object.
Note If you do not implement the IEditableObject interface, changes cannot be rolled back. Keep this in mind as you decide which approach is right for the problem you are solving.
Below 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. For more information about how the BeginEdit, EndEdit, and CancelEdit methods work, see Introduction to Dataset Updates.
- BeginEdit method
Signals the start of an edit on an object. An object implementing this interface will need to store any updates after the BeginEdit method call in such a way that they can be discarded if the CancelEdit method is called. In data binding Windows Forms, you can call this method multiple times within the scope of a single edit transaction (for example, BeginEdit,BeginEdit,EndEdit). Implementations of the IEditableObject interface should keep track of whether the 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 non-destructive; 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.
- EndEdit method
Pushes any changes since BeginEdit was called into the underlying object, if the object is currently in edit mode.
- CancelEdit method
Discards any changes made to the object.
This "transactional" notion of data functionality is used by the DataGrid control.
- BeginEdit method
- IDataErrorInfo interface
- A class that implements the IDataErrorInfo interface, which allows objects to offer custom error information that controls can bind to. This implementation provides the highest level of data-binding functionality. In particular, it returns two strings: