On re-bind's data source controls

Owned by reinhard reinhard (Unlicensed)
Last updated: Jan 20, 2010Version comment

Data source controls shield the retrieval and interfacing of data from the display of that data. ASP.NET 2.0 provides all sorts of data sources, for example:

  • An SqlDataSource provides tabular data stored in an SQL database. A GridView or FormView can bind to (i.e. get data from) such a data source for displaying the tabular data.
  • A SiteMapDataSource provides hierarchical data representing the hierarchy of a website. A tree-control can bind to such a data source for navigating the website.
    In other words: data source controls relay data to other controls for display. Data source controls keep configuration details (database connection, type of database) out of the application code. Data source controls are usually invisible, because they are supposed to work in the background for an application.
    re-bind comes with its own set of data sources, and it is the binding from data sources to BOC controls that give re-bind its name. In contrast to most ASP.NET controls, re-bind provides two -way data-binding: data sources cannot only relay data to a control, but also modify data based on user input into the bound controls.
    re-bind expects data source controls binding to business objects to implement the IBusinessObjectDataSource interface. Currently there are two concrete implementations for this interface:
  • BindableObjectDataSource - provides data stored in a BindableObject for BOC controls
  • BusinessObjectReferenceDataSource - behaves like a data source towards a control; behaves like a control towards a data source (more about that in a minute)
BindableObjectDataSource

The BindableObjectDataSource is the bread and butter for every re-bind hacker, because the all-important BOC controls (BocTextValue, BocEnumValue, etc.) expect to get their data from a BindableObjectDataSource. A BindableObjectDataSource always knows the type (class) of object instance it binds to. After association of the data source with an instance, controls can retrieve property values from that object, or update properties based on user input. You don't need to look far to find examples for this. A BindableObjectDataSource is a regular staple on every re-call page/function generated by uigen.exe. If you look at EditLocationControl.ascx (part of the re-call page/function EditLocationForm.aspx) you will find this declaration for a BindableObjectDataSource:

<remotion:BindableObjectDataSourceControl ID="CurrentObject"
                                          runat="server"
                                          Type="PhoneBook.Domain.Location, PhoneBook.Domain" />

In this declaration, the data source gets an ID, so that other (BOC) controls can reference it. The Type simply is a constraint for the objects the data source expects (plus the name of the assembly where that particular type is declared = full name).

Each of the BocTextValue|s in the edit control references that BindableObjectDataSource and tells it which property in the bound object corresponds to that BocTextValue. The Street property, for example:

<remotion:BocTextValue ID="StreetField"
                       runat="server"
                       DataSourceControl="CurrentObject"
                       PropertyIdentifier="Street" >

This snippet asks the CurrentObject data source listed above to provide the value Location's Street property. The most interesting part (besides the DataSourceControl) is the PropertyIdentifier. It specifies which property of the bound Location object the control wants.
Again, re-bind bindings work both ways. A BindableObjectDataSource not only relays data for reading, but also for writing. If the StreetField has its text value changed by the user, it tells the data source to write that value into the Street property of the Location instance currently bound to the data source as soon as the data source is written to the database.

BusinessObjectReferenceDataSource

A BusinessObjectReferenceDataSource can be used for "mirroring" complete objects into forms – sometimes a welcome optimization and time-saver for both programmers and users of an application. Here is an illustration:

In the illustration above, a Company object references a SpokesPerson object. For user convenience, the property values for the spokesperson - name and phone-number - are displayed on the same page as the company property values.
In this example, the page for display has two data sources:

  • the usual BindableObjectDataSource provides the property values for the Company object
  • the BusinessObjectReferenceDataSource tells that BindableObjectDataSource that it is a control (like a BocTextValue, for example) and needs the value stored in the reference property SpokesPerson.
    The BusinessObjectReferenceDataSource follows the reference to worm its way through to the two property values of the referenced object. These values are then provided to the controls on the form for display. When dealing with these controls, the BusinessObjectReferenceDataSource acts just like a regular data source for the controls that bind to it (Name and Phone, in this case). For these controls the BusinessObjectReferenceDataSource can transparently be used just like a regular data source (BindableObjectDataSource), complete with property paths.
    The beauty of this scheme is that no matter where the SpokesPerson property in the Company object points to, the BusinessObjectReferenceDataSource and the BindableObjectDataSource will always do the right thing and retrieve the corresponding values for the referenced spokesperson's name and phone-number.