Asp.net| Control | data | Data source control is a new server control introduced in Microsoft Visual Studio 2005, a key part of the data-binding architecture that provides declarative programming models and automatic data-binding behavior through data-bound controls. This article and subsequent articles in this series will introduce the core content of the implementation data source control.
Introduction
In short, a data source control outlines a data store and some operations that can be performed on the contained data. The databound control is associated with a data source control through its DataSourceID property. Most traditional data stores are either tabular or hierarchical, and the data source controls are grouped into two categories. Here you want to describe the data source control in tabular format.
The data source control itself does not work as much; all logic is encapsulated in DataSourceView derived classes. At least one DataSourceView must implement the function of retrieving (that is, SELECT) a set of rows. It provides the ability to modify data (that is, INSERT, UPDATE, and DELETE) (optional). Data-bound controls are available through a variety of can??? property to check the enabled feature set. The data source control itself is simply a container for one or more unique named views. By convention, the default view can be accessed by its name, or it can be empty. The relationship between different views or relationships can be appropriately defined based on the implementation of each data source control. For example, a data source control might provide a different filtered view of the same data through different views, or it might provide a set of child rows in a secondary view. You can use the DataMember property of a data-bound control to select a particular view (if the data source control provides multiple views). Note that none of the built-in data source controls in Whidbey currently provide multiple views.
Finally, let me introduce a little bit of content. Data source controls (and their views) implement two sets of APIs. The first set of APIs is an abstract interface defined for four commonly used data operations, and is used in any data-bound control in general terms. The second group is optional, defined by the terms of the domain or data store it represents, is typically strongly typed, and is intended for application developers.
Sample
In these articles, you will implement a weatherdatasource that will work with the REST (English) XML API provided by weather.com to retrieve weather information based on the ZIP code. The derived data source control is typically implemented first.
public class Weatherdatasource:datasourcecontrol {
public static readonly string
Currentconditionsviewname = "Currentconditions";
Private WeatherDataSourceView _currentconditionsview;
Private WeatherDataSourceView Currentconditionsview {
get {
if (_currentconditionsview = = null) {
_currentconditionsview = new WeatherDataSourceView (this, currentconditionsviewname);
}
return _currentconditionsview;
}
}
public string ZipCode {
get {
string s = (string) viewstate["ZipCode"];
return (s!= null)? S:string.empty;
}
set {
if (String.Compare (value, ZipCode,
stringcomparison.ordinal)!= 0) {
viewstate["ZipCode"] = value;
Currentconditionsview.raisechangedevent ();
}
}
}
protected override DataSourceView GetView (string viewName) {
if (String.IsNullOrEmpty (viewName) | |
(String.Compare (ViewName, Currentconditionsviewname,
stringcomparison.ordinalignorecase) = = 0)) {
return currentconditionsview;
}
throw new ArgumentOutOfRangeException ("ViewName");
}
protected override ICollection GetViewNames () {
return new string[] {currentconditionsviewname};
}
Public Weather GetWeather () {
return Currentconditionview.getweather ();
}
}
As you can see, the basic idea is to implement GetView to return a named view instance and implement GetViewNames to return the set of available views.
This selection derives from DataSourceControl. One thing is imperceptible, in fact the data-bound control is looking for the IDataSource interface, and the DataSource control implements the interface by implementing GetView and GetViewNames. The interface is needed to enable the data source control to be both tabular and hierarchical (if possible), deriving from the main model and implementing another model as an interface in this case. Second, other controls are also allowed to be converted in various scenarios to double the capacity of the data source. Also note the common ZipCode property and the GetWeather method that returns the strongly typed Weather object. This API is suitable for page developers. Page developers need not consider DataSourceControl and DataSourceView.
[1] [2] Next page
