Arbeiten mit typisierten DataSets

[Frank H]

Hallo,

beim Erstellen eines typisierten DataSets muss man beim Erstellen bekanntlich eine Datenverbindung angeben. Somit ist es mit einem bestimmten Datenprovider verknüpft.
Was kann man tun, wenn man sich die Möglichkeit offenhalten möchte, auch andere Datenprovider zu verwenden? Kann man dann überhaupt typisierte DataSets einsetzen?

Vielen Dank,
Frank

[Jürgen Thomas]

Hallo Frank,

das geht auf jeden Fall. Die "automatisch erzeugte" DB-Verbindung gibt es primär durch den Assistenten von Visual Studio, hat aber mit dem typ. Dataset eigentlich wenig zu tun: Das DataSet repräsentiert die Datenmenge/n intern im Arbeitsspeicher; die DB-Verknüpfung wird dagegen durch DbDataAdapter oder DbDataReader hergestellt. Visual Studio schmeißt beides zusammen.

Ich bitte die Fans von Visual Studio, nicht aufzuschreien wegen dieser Verkürzung. Ich arbeite mit #D und richte mich danach, dass ADO.NET die Datenhaltung und Datenverarbeitung eigentlich trennt.

Wenn Du unabhängig davon mit typ. DataSet arbeiten willst, kannst Du beispielsweise so vorgehen:

• Erzeuge (auf welchem Weg auch immer) ein beliebiges DataSet.
• Speichere die Struktur mit WriteXmlSchema() als xsd-Datei.
• Erzeuge mit xsd.exe (ist im NET-SDK enthalten) das typ. DataSet zu dieser Struktur.
• Mit partial class kannst Du die erzeugte Quelldatei um eigene Funktionalität erweitern.

Nachdem ich die Struktur der xsd-Datei verstanden hatte, verfahre ich jetzt meistens so: Zuerst erstelle ich manuell per einfachen Texteditor die xsd-Datei zu einer Liste von Datenmengen; diese Datei bekommt gleich den Namen ThisDataSet.Designer.xsd; dann gehe ich mit xsd.exe darüber; dann verbinde ich die ThisDataSet.Designer.cs mit einer einfachen partial class ThisDataSet in der Datei ThisDataSet.cs - fertig.

Du siehst, dass bei meinem Vorgehen nirgends die Verbindung zu einer realen DB existiert. Diese stecke ich in eine eigene DBConnector-Klasse, wo ich mich mit einem beliebigen DbProvider vergnügen kann und die DataTables beliebig mit Inhalt füllen kann.

Viel Erfolg! Jürgen

[Andreas Kosch]

Hallo Jürgen,

Visual Studio schmeißt beides zusammen

ab Visual Studio 2008 trennt der Wizard auf Wunsch (Eigenschaft DataSet Project) das typisierte DataSet in 2 Klassenbibliothen, so dass der datenbankspezifische TableAdapter in einer separatem Assembly landet. Somit entfällt der manuelle Mehraufwand für die Trennung vollständig ;-)

[mirkom76]

Hallo Andreas,

sind unter Visual Studio 2008 die typisierten Datasets schneller geworden? Bisher habe ich das ganze immer als sehr langsam empfunden, vor allem bei Updates.

Ist da in Sachen Performance etwas passiert?

[Andreas Kosch]

Hallo,

Bisher habe ich das ganze immer als sehr langsam empfunden, vor allem bei Updates.

Bereits seit .NET 2.0 kann die Eigenschaft UpdateBatchSize verwendet werden, um beim Update-Aufruf von vielen geänderten Datensätzen den Aufruf in einen einzigen Zugriff auf den SQL-Server zu bündeln:

namespace TableAdapterUpdateBatchSize.tempdbDataSetTableAdapters
{
*** partial class TestTblTableAdapter
*** {
*** *** /// <summary>
*** *** /// Wenn die SqlDataAdapter-Eigenschaft UpdateBatchSize auf einen 
*** *** /// anderen Wert als 1 gesetzt werden soll, muss vorher die Default-
*** *** /// Einstellung Both für die SqlCommand-Eigenschaft UpdatedRowSource 
*** *** /// auf den Wert UpdateRowSource.OutputParameters geändert werden 
*** *** /// (wobei dies zur Laufzeit nur dann erfolgreich ist, wenn auch die 
*** *** /// vom TableAdapter eingebundenen Stored Procedure die aktuellen Daten
*** *** /// über OUTPUT-Parameter zurückliefern).
*** *** /// </summary>
*** *** public void SetTableAdapterUpdatedRowSourceOutputParameter()
*** *** {
*** *** *** this.Adapter.InsertCommand.UpdatedRowSource = UpdateRowSource.OutputParameters;
*** *** *** this.Adapter.UpdateCommand.UpdatedRowSource = UpdateRowSource.OutputParameters;
*** *** }
*
*** *** /// <summary>
*** *** /// Veröffentlicht die SqlDataAdapter-Eigenschaft UpdateBatchSize. 
*** *** /// Wenn ein Wert ungleich 1 gesetzt werden soll, muss vorher die 
*** *** /// UpdatedRowSource-Eigenschaft von InsertCommand und UpdateCommand 
*** *** /// über SetTableAdapterUpdatedRowSourceOutputParameter gesetzt werden.
*** *** /// </summary>
*** *** public int TableAdapterUpdateBatchSize
*** *** {
*** *** *** get
*** *** *** {
*** *** *** *** return (this.Adapter.UpdateBatchSize);
*** *** *** }
*** *** *** set
*** *** *** {
*** *** *** *** this.Adapter.UpdateBatchSize = value;
*** *** *** }
*** *** }
*** }
}

Das Ergebnis zeigt die angehängte Abbildung: Wenn 5000 geänderte Datensätze über Update gespeichert werden, verringert sich die Zeit um ca. 40 %, weil nicht mehr 5000 einzelne UPDATE-Anweisungen zum SQL-Server geschickt werden, sondern stattdessen nur zusammengefasste Blöcke der eingestellte Größe.

[Frank H]

Argument für xsd.exe

Hallo,

als Argument für die XSD-Dateioptionen gebe ich immer /d[ataset] an, damit ein typisiertes DataSet erzeugt wird. Sehe ich das richtig, dass das Argument /c[lasses] nur zum Erzeugen von Objekten sonstiger Klassen gedacht ist?

Frank

[Andreas Kosch]

Hallo,

das Kommandozeilen-Tool XSD.EXE ist ein universell nutzbares Werkzeug, dass zum Beispiel auch aus einer XML-Datei das XML Schema (*.xsd) ableiten kann. Der Schalter /c legt basierend auf einem XML Schema die Zugriffsklassen auf die XML-Struktur an (diese Technik war bei VS2005 üblich, wenn man einen XML Web Service streng nach den Contract First-Regeln entwickeln wollte).