Datenquellensteuerelemente sind eine neue Art von Serversteuerelementen, die in Microsoft Visual Studio 2005 eingeführt wurden. Sie sind ein wichtiger Bestandteil der Datenbindungsarchitektur und können durch Datenbindungssteuerelemente ein deklaratives Programmiermodell und automatisches Datenbindungsverhalten bereitstellen. In diesem Artikel und den folgenden Artikeln dieser Reihe werden die Kernelemente der Implementierung von Datenquellenkontrollen vorgestellt.
Einführung
Kurz gesagt, ein Datenquellen-Steuerelement fasst einen Datenspeicher und einige Vorgänge zusammen, die für die enthaltenen Daten ausgeführt werden können. Das DataBound-Steuerelement ist über seine DataSourceID-Eigenschaft mit einem Datenquellensteuerelement verknüpft. Die meisten herkömmlichen Datenspeicher sind entweder tabellarisch oder hierarchisch, und die Datenquellenkontrollen sind entsprechend unterteilt. Was wir hier vorstellen möchten, ist die Datenquellenkontrolle im Tabellenformat.
Die Datenquellensteuerung selbst leistet nicht viel; die gesamte Logik ist in von DataSourceView abgeleiteten Klassen gekapselt. Mindestens eine DataSourceView muss die Funktion zum Abrufen (d. h. Auswählen) einer Reihe von Zeilen implementieren. Es kann die Funktion zum Ändern von Daten (z. B. INSERT, UPDATE und DELETE) bereitstellen (optional). Datengebundene Steuerelemente können aktivierte Funktionssätze über verschiedene Can???-Eigenschaften überprüfen. Die Datenquellensteuerung selbst ist nur ein Container für eine oder mehrere eindeutig benannte Ansichten. Konventionell kann auf die Standardansicht über ihren Namen zugegriffen werden oder sie kann leer sein. Ob und welche Art von Beziehung zwischen verschiedenen Ansichten besteht, kann basierend auf der Implementierung der einzelnen Datenquellenkontrollen entsprechend definiert werden. Beispielsweise könnte ein Datenquellen-Steuerelement verschiedene gefilterte Ansichten derselben Daten über verschiedene Ansichten bereitstellen, oder es könnte eine Reihe von Unterzeilen in einer sekundären Ansicht bereitstellen. Sie können die DataMember-Eigenschaft eines datengebundenen Steuerelements verwenden, um eine bestimmte Ansicht auszuwählen (wenn das Datenquellensteuerelement mehrere Ansichten bereitstellt). Bitte beachten Sie, dass derzeit keine der integrierten Datenquellensteuerungen in Whidbey mehrere Ansichten bietet.
Abschließend möchte ich einige Inhalte vorstellen. Datenquellensteuerelemente (und ihre Ansichten) implementieren zwei Sätze von APIs. Der erste Satz von APIs ist eine abstrakte Schnittstelle, die für vier allgemeine Datenoperationen definiert ist und regelmäßig von jedem datengebundenen Steuerelement aus verwendet werden kann. Die zweite Gruppe ist optional, wird anhand der Domäne oder des Datenspeichers definiert, die sie darstellt, ist normalerweise stark typisiert und für Anwendungsentwickler gedacht.
Beispiel
In diesen Artikeln implementieren Sie eine WeatherDataSource, die mit der von Weather.com (Englisch) bereitgestellten REST-XML-API (Englisch) arbeitet, um Wetterinformationen basierend auf der Postleitzahl abzurufen. Abgeleitete Datenquellenkontrollen werden normalerweise zuerst implementiert.
öffentliche Klasse WeatherDataSource: DataSourceControl {
öffentliche statische schreibgeschützte Zeichenfolge
CurrentConditionsViewName = "CurrentConditions";
private WeatherDataSourceView _currentConditionsView;
private WeatherDataSourceView {
erhalten {
if (_currentConditionsView == null) {
_currentConditionsView = new WeatherDataSourceView(this, CurrentConditionsViewName);
}
return _currentConditionsView;
}
}
öffentliche Zeichenfolge Postleitzahl {
erhalten {
string s = (string)ViewState["ZipCode"];
return (s != null) ? s : String.Empty;
}
Satz {
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 };
}
öffentliches Wetter GetWeather() {
return CurrentConditionView.GetWeather();
}
}
Wie Sie sehen, besteht die Grundidee darin, GetView zu implementieren, um eine benannte Ansichtsinstanz zurückzugeben, und GetViewNames, um den Satz verfügbarer Ansichten zurückzugeben.
Wählen Sie hier „Von DataSourceControl ableiten“. Was nicht leicht zu erkennen ist, ist, dass das datengebundene Steuerelement tatsächlich nach der IDataSource-Schnittstelle sucht und das DataSource-Steuerelement die Schnittstelle durch die Implementierung von GetView und GetViewNames implementiert. Der Grund, warum die Schnittstelle benötigt wird, besteht darin, dass die Datenquellensteuerung sowohl tabellarisch als auch hierarchisch sein kann (falls möglich, in diesem Fall vom Hauptmodell ableiten und ein anderes Modell als Schnittstelle implementieren). Zweitens ermöglicht es auch die Konvertierung anderer Steuerelemente in verschiedenen Szenarien, um die Kapazität der Datenquelle zu verdoppeln. Beachten Sie auch die öffentliche ZipCode-Eigenschaft und die GetWeather-Methode, die ein stark typisiertes Weather-Objekt zurückgibt. Diese API ist für Seitenentwickler geeignet. Seitenentwickler müssen nicht über DataSourceControl und DataSourceView nachdenken.
Der nächste Schritt besteht darin, die Datenquellenansicht selbst zu implementieren. Dieses spezielle Beispiel stellt nur Funktionen auf SELECT-Ebene bereit (dies ist die Mindestanforderung und die einzige Funktionalität, die in diesem Szenario nützlich ist).
private versiegelte Klasse WeatherDataSourceView: DataSourceView {
private WeatherDataSource _owner;
public WeatherDataSourceView(WeatherDataSourceowner, string viewName)
: base(owner, viewName) {
_owner = Eigentümer;
}
protected override IEnumerable ExecuteSelect(
DataSourceSelectArguments-Argumente) {
arguments.RaiseUnsupportedCapabilitiesError(this);
Weather WeatherObject = GetWeather();
return new Weather[] { WeatherObject };
}
internes Wetter GetWeather() {
string zipCode = _owner.ZipCode;
if (zipCode.Length == 0) {
throw new InvalidOperationException();
}
WeatherService WeatherService = new WeatherService(zipCode);
return WeatherService.GetWeather();
}
internal void RaiseChangedEvent() {
OnDataSourceViewChanged(EventArgs.Empty);
}
}
Standardmäßig gibt die DataSourceView-Klasse „false“ von Eigenschaften wie „CanUpdate“ zurück und löst eine „NotSupportedException“ von „Update“ und verwandten Methoden aus. Das Einzige, was Sie hier in der WeatherDataSourceView tun müssen, ist, die abstrakte ExecuteSelect-Methode zu überschreiben und ein IEnumerable zurückzugeben, das die „ausgewählten“ Wetterdaten enthält. In der Implementierung wird eine Hilfsklasse WeatherService verwendet, die einfach ein WebRequest-Objekt verwendet, um Weather.com (auf Englisch) anhand der ausgewählten Postleitzahl abzufragen (daran ist nichts Besonderes).
Möglicherweise ist Ihnen aufgefallen, dass ExecuteSelect als geschützt markiert ist. Was das datengebundene Steuerelement tatsächlich aufruft, ist die öffentliche (und versiegelte) Select-Methode, die im Rückruf übergeben wird. Die Implementierung von Select ruft ExecuteSelect auf und ruft den Rückruf mit der resultierenden IEnumerable-Instanz auf. Dieses Muster ist sehr seltsam. Dafür gibt es einen Grund, der in den folgenden Artikeln dieser Serie erläutert wird. Bitte warten...
Hier ist ein Beispiel für diese Verwendung:
Postleitzahl: <asp:TextBox runat="server" id="zipCodeTextBox" />
＜asp:Button runat="server" onclick="OnLookupButtonClick" Text="Look" /＞
＜hr /＞
＜asp:FormView runat="server" DataSourceID="weatherDS"＞
<ItemTemplate>
<asp:Label runat="server"
Text='＜%# Eval("Temperature", "Die aktuelle Temperatur ist {0}.") %＞' /＞
＜/ItemTemplate＞
＜/asp:FormView＞
＜nk:WeatherDataSource runat="server" id="weatherDS" ZipCode="98052" /＞
＜script runat="server"＞
private void OnLookupButtonClick(object sender, EventArgs e) {
WeatherDS.ZipCode = zipCodeTextBox.Text.Trim();
}
</script>
Dieser Code legt die Postleitzahl als Reaktion auf Benutzereingaben fest, was dazu führt, dass die Datenquelle eine Änderungsbenachrichtigung ausgibt, wodurch das gebundene FormView-Steuerelement die Datenbindung durchführt und die Anzeige ändert.
Jetzt ist der Datenzugriffscode in der Datenquellensteuerung gekapselt. Darüber hinaus ermöglicht dieses Modell Weather.com (auf Englisch), eine Komponente zu veröffentlichen, die auch dienstspezifische Details kapseln kann. Hoffentlich klappt es. Darüber hinaus ermöglicht die abstrakte Datenquellenschnittstelle, dass FormView nur mit Wetterdaten arbeitet.
Im nächsten Artikel erweitern Sie die Datenquellensteuerung, um Änderungen am Filterwert (d. h. der Postleitzahl), der zum Abfragen der Daten verwendet wird, automatisch zu verarbeiten.