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. AGridView
orFormView
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 theIBusinessObjectDataSource
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
:
...
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 theCompany
object - the
BusinessObjectReferenceDataSource
tells thatBindableObjectDataSource
that it is a control (like aBocTextValue
, for example) and needs the value stored in the reference propertySpokesPerson
.
TheBusinessObjectReferenceDataSource
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, theBusinessObjectReferenceDataSource
acts just like a regular data source for the controls that bind to it (Name
andPhone
, in this case). For these controls theBusinessObjectReferenceDataSource
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 theSpokesPerson
property in theCompany
object points to, theBusinessObjectReferenceDataSource
and theBindableObjectDataSource
will always do the right thing and retrieve the corresponding values for the referenced spokesperson's name and phone-number.