Einfachere SQL-Abfragen mit Data Access Application Block

Obwohl Microsofts .NET Application Block sehr gut dokumentiert ist, sind praktische Tipps und Tricks nicht leicht zu finden. Deshalb publiziert ZDNet hier verschiedene Codes, mit denen Data Access Application Block in .NET/SQL-Server-Projekten einfacher einzusetzen ist.

Vorbereitungen
Data Access Application Block lässt sich von MSDN herunterladen. Es ist notwendig, das Paket zu installieren, und bevor man ein Projekt laden kann, müssen die Komponenten mit Visual Studio .NET 2002 oder 2003 gebaut werden. Außerdem muss man auf die erstellte DLL im /bin/-Verzeichnis im Verknüpfungsordner des Projekts, in dem die Komponenten genutzt werden sollen, verweisen. Schließlich wird noch eine Assemblerreferenz zu jeder Datei oder Form wie folgt benötigt:



Grundlegende Verwendung
Die Hauptklasse von Data Access Application Block ist SQLHelper, eine geschlossene Klasse mit vier üblichen (und etlichen seltener benutzten) Methoden:

  • ExecuteDataset generiert ein DataSet von einer SQL-Abfrage.
  • ExecuteReader generiert einen SqlDataReader von einer SQL-Abfrage.
  • ExecuteScalar generiert ein eindeutiges Objekt von einer SQL-Abfrage.
  • ExecuteNonQuery führt eine SQL-Abfrage ohne Rückgabewert durch.

Hier ein näherer Blick auf die einzelnen Methoden.

ExecuteDataset
ExecuteDataset führt die grundlegende SELECT-Abfrage durch und generiert ein DataSet, das dann an ein Serverobjekt angebunden oder zum Erstellen einer DataView verwendet werden kann. Wie bei allen anderen Methoden gibt es auch etliche Überladungen. Die am weitesten verbreitete Version sieht aber etwa so aus:



Üblicherweise bestückt man ein DataSet von einer SELECT-Abfrage mit einer RowId oder einem Suchparameter. Der oben genannte. Parameterblock kann viele Parameter aufnehmen. Daher bräuchte man z.B. selbst bei der Übergabe von drei Suchparametern nur:



ExecuteReader
Auch ExecuteReader ist für ein SELECT-Statement bestimmt, jedoch üblicherweise für Situationen reserviert, bei denen es wirklich auf Performance ankommt. SqlDataReaders sind wie forward-only, read-only Recordsets des klassischen ADO. Sie eignen sich zum Befüllen von Listenfeldern und Checkbox-Listen. Bevor man jedoch losstürmt und 300 SqlDataReader aufruft, um die dynamischen Kontrollelemente auszufüllen, sollte man sich den abschließenden Kommentar im Abschnitt „Allgemeine Hinweise“ zu Gemüte führen.

Der Aufruf von ExecuteReader sieht wie ein ExecuteDataset aus. Nicht vergessen: Eine Assemblerreferenz zu System.Data.SqlClient ist erforderlich, um SqlDataReader mit einer SQL-Server-Datenbank zu verwenden:



ExecuteScalar
Die Methode ExecuteScalar wird für vielerlei eingesetzt, etwa für die Rückgabe einer SELECT-Abfrage mit nur einem Wert wie beispielsweise COUNT. Am häufigsten wird sie jedoch dafür benutzt, ein INSERT-Statement auszuführen, das die neue RowId zurückgibt. Das ist ein ziemlich üblicher Trick in Transact SQL, er macht aber eine Datentypkonvertierung (CAST) in der Stored Procedure erforderlich, um sicherzustellen, dass die resultierende RowId in dem für .NET einfachsten Format zurückgegeben wird.



Der Einfachheit halber wird der Wert als Objekt an .NET zurückgegeben. Mit dem Convert-Statement erhält man eine ganzzahlige RowId.



ExecuteNonQuery
Mit ExecuteNonQuery wird alles andere ausgeführt, was keine Werte zurückgibt: UPDATE, DELETE und funktionelle Abfragen oder Housekeeping. Auch hier entspricht der Vorgang den anderen Methoden, mit den Argumenten Connection-String, Stored Procedure und Parameter(n).



Themenseiten: Anwendungsentwicklung, Big Data, Datenbank, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Einfachere SQL-Abfragen mit Data Access Application Block

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *