• Choose a category
• All
• Classic-Fiction

Let’s explore in more detail the various data-binding properties.

Note

For some reason, the Repeater control—a low-level iterative control—doesn’t inherit from either of the classes in the diagram. It inherits directly from the Control class. In spite of this, Repeater has everything that’s needed to be considered an iterative control.

The DataSource Property

The DataSource property lets you specify the data source object the control is linked to.

Note that this link is logical and does not result in any overhead or underlying operation until you explicitly choose to bind the data to the control. This operation is triggered by calling the DataBind method. When the DataBind method executes, the control actually loads data from the associated data source, evaluates the data-bound properties (if any), and generates the markup to reflect changes. The property is defined as follows:

public virtual object DataSource {get; set;}

The DataSource property is declared of type object and can ultimately accept objects that implement either IEnumerable (including data readers) or IListSource. By the way, only DataSet and DataTable implement the IListSource interface.

The DataSource property of a data-bound control is generally set programmatically. However, nothing prevents you from adopting a kind of declarative approach as follows:

...

/>

The content of the drop-down list control will be determined by the object returned by the GetData method. In this example, GetData is a public or protected member of the code-behind page class that returns a bindable object. The # symbol in the code block indicates that the expression will be evaluated only after a call is made to the method DataBind on the page that contains the DropDownList control or on the control itself.

Note

How can a data-bound control figure out which actual object it is bound to? Will it be a collection, a data reader, or perhaps a DataTable?

All standard data-bound controls are designed to work only through the IEnumerable interface. For this reason, any object bound to DataSource is normalized to an object that implements IEnumerable. In some cases, the normalization is as easy (and fast) as casting the object to the IEnumerable interface. In other cases—specifically, when DataTable and DataSet are involved—an extra step is performed to locate a particular named collection of data that corresponds to the value assigned to the DataMember property.

There’s no public function to do all this work, although a similar helper class exists in the ASP.NET framework but is flagged as internal. What this helper class does, though, can be easily replicated by custom code: it just combines an array of if statements to check types and does casting and conversion as appropriate.

The DataSourceID Property

The DataSourceID property gets or sets the ID of the data source component from which the data-bound control retrieves its data. This property is the point of contact between data-bound controls and a special family of controls—the data source controls—that includes SqlDataSource and ObjectDataSource. (I’ll cover these controls in more detail later in the chapter.)

public virtual string DataSourceID {get; set;}

By setting DataSourceID, you tell the control to turn to the associated data source control for any needs regarding data—retrieval, paging, sorting, counting, or updating.

Like DataSource, DataSourceID is available on all data-bound controls. The two properties are mutually exclusive. If both are set, you get an invalid operation exception at run time. Note, though, that you also get an exception if DataSourceID is set to a string that doesn’t correspond to an existing data source control.

The DataMember Property

The DataMember property gets or sets the name of the data collection to extract when data binding to a data source:

public virtual string DataMember {get; set;}

You use the property to specify the name of the DataTable to use