# 23 ADO.NET – verbindungsorientierte Objekte Vor der Einführung von ADO.NET im Jahr 2002 hat Microsoft verschiedene Technologien für den Zugriff und das Speichern von Daten eingesetzt. Der direkte Vorgänger von ADO.NET war Microsoft ActiveX Data Objects (ADO), eine verbindungsorientierte Datenzugriffstechnologie, der allerdings Schlüsselfunktionen für große, verteilte Anwendungen fehlen. Von der Idee her soll ADO.NET den Entwicklern dabei helfen, mehrschichtige Datenbankanwendungen über Intranets und das Internet hinweg zu erstellen. Daraus resultiert eine zweischichtige Klassenarchitektur: Es gibt einerseits Klassen, deren Objekte sich direkt mit der Datenbank austauschen, und andererseits Klassen, deren Objekte als unverbundene Objekte bezeichnet werden. Letztgenannte sind völlig unabhängig von der Datenquelle, aus der die Daten stammen. In Konsequenz dieser Aussage sind alle Objekte von ADO.NET zwei Gruppen zuzuordnen: verbundene Objekte unverbundene Objekte Zu den verbundenen Objekten zählen unter anderem die Klassen Connection, Command und DataAdapter, zu den unverbundenen die Klasse DataSet und DataTable. Auf alle werden wir im Verlauf dieses und der folgenden Kapitel noch eingehen. ADO.NET beschränkt sich nicht nur auf Datenbanken. Im Grunde genommen können Sie jede beliebige Datenquelle ansprechen, so sie denn ODBC- oder OleDB-fähig ist. Beispielsweise ist es kein Problem, Daten aus einer Microsof-Excel-Tabelle zu importieren oder in diese zu exportieren. Da man im Grunde genommen davon ausgehen kann, dass jede ernstzunehmende Datenbank entweder ODBC oder OleDB unterstützt, kann ADO.NET mit praktisch jeder Datenbank kommunizieren. Mit Visual Studio 2010 wird standardmäßig auch die SQL Server 2008 Express Edition installiert. Was liegt also näher, als diesen Datenbank-Server als Grundlage aller weiteren Betrachtungen zu nehmen. Leider fehlen dieser Version Administrationsprogramme, die mit der Vollversion ausgeliefert werden. Sie können aber das SQL Server 2008 Management Studio Express kostenlos bei Microsoft herunterladen. Was Ihnen anschließend noch fehlt, ist eine gute Beispieldatenbank. In diesem und den folgenden Kapiteln werde ich mit einer allbekannten und bewährten Datenbank arbeiten, die ich für Lernzwecke für ausgezeichnet halte: Northwind. Diese Datenbank kann ebenfalls aus dem Internet kostenlos heruntergeladen und anschließend installiert werden. Folgen Sie dazu dem folgenden Link: http://msdn.microsoft.com/de-de/library/ms143221.aspx Sie erhalten dann die Datei SQL2000SampleDb.msi. Wenn Sie auf die Datei doppelklicken, werden Sie durch einen Installationsprozess geführt, der das Verzeichnis SQL Server 2000 Sample Databases erzeugt und dort die entsprechenden Skriptdateien ablegt. Im Microsoft SQL Server Management Studio können Sie über Datei • Öffnen • Datei die Skriptdatei auswählen. Abschließend klicken Sie noch auf den Button Ausführen in der Symbolleiste. Das war’s. Damit sind alle vorbereitenden Maßnahmen zum Einstieg in dieses und die folgenden Kapitel erfolgt. Zumindest Grundkenntnisse in der Datenmodellierung und in SQL werden in diesem Kapitel vorausgesetzt. ## 23.1 Datenprovider Die erste Frage, die es zu klären gilt, ist die, aus welcher Datenquelle die Daten bezogen werden sollen. Damit entscheidet sich auch, welcher Datenprovider zum Einsatz kommt. Das .NET Framework stellt vier zur Verfügung: SqlClient-Provider OleDb-Provider Odbc-Provider Oracle-Provider Ein Datenprovider ist eine Klassenbibliothek, die für den Zugriff auf einen bestimmten Datenspeichertyp geprägt ist. Jeder .NET-Datenprovider implementiert dabei die gleichen Klassen, beispielsweise Connection, Command oder DataAdapter. Der tatsächliche Name hängt vom gewählten Provider ab. So bietet der SqlClient-Provider beispielsweise die Klasse SqlConnection an und der OleDb-Datenprovider die Klasse OleDbConnection. Unabhängig davon, für welchen Datenprovider Sie sich entscheiden, bleiben die Schnittstellen und damit die Funktionalitäten gleich. Nahezu unabhängig von der Providerwahl ist auch der Programmcode. Sollten Sie gezwungenermaßen zu einem späteren Zeitpunkt den Provider wechseln, brauchen Sie möglicherweise den Programmcode überhaupt nicht oder nur geringfügig zu überarbeiten. Häufig sind Sie nicht auf einen einzigen Datenprovider festgelegt, sondern können für den Zugriff auf eine Datenquelle zwischen mehreren auswählen. Ist die Datenquelle ein Microsoft SQL Server in der Version 7.0 oder höher, empfiehlt sich der SqlClient-Datenprovider, weil dieser für die genannten Versionen des SQL Servers optimiert ist. Aber auch über den OleDb- oder Odbc-Provider kann der SQL Server abgefragt werden. Jeder .NET-Datenprovider hat einen eigenen Namespace, der ein Unter-Namespace von System.Data ist und mit using bekannt gegeben werden sollte. Beabsichtigen Sie den Zugriff auf eine Oracle-Datenbank mit dem Oracle-Provider, müssen Sie die Assembly System.Data.OracleClient.dll in die Anwendung einbinden.