Skip to main content
ADO.NET 2.0
Veröffentlicht: 19. Mai 2005
Von Jürgen Mauerer

ADO.NET 2.0 bietet ein erweitertes Provider-Modell, echte Provider-unabhängige Programmierung, ist auf das Zusammenspiel mit dem SQL Server 2005 ausgelegt und offeriert eine Reihe weiterer neuer Funktionen. Dieses Feature zeigt auf Basis der Beta 2, welche Verbesserungen ADO.NET 2.0 für Entwickler bringt.

Auf dieser Seite

ADO.NET 2.0 - eine Einführung ADO.NET 2.0 - eine Einführung
Wichtige neue Funktionen Wichtige neue Funktionen
Funktionen speziell für SQL Server 2005 Funktionen speziell für SQL Server 2005

ADO.NET 2.0 - eine Einführung

ADO.NET 2.0 ist Teil des .NET Framework 2.0 und befindet sich dort im Namensraum System.Data. Microsoft hat die Datenzugriffs-API mit vielen Neuerungen versehen, ADO.NET aber nicht komplett umgebaut. Im Prinzip handelt es sich beim Objektmodell von ADO.NET 2.0 um eine rückwärtskompatible Erweiterung des Vorgängers. Der Datenzugriff in .NET 2.0 wurde auch durch den Ausbau der datengebundenen Steuerelemente in Windows Forms und Web Forms sowie durch zusätzliche Funktionen in Visual Studio 2005 verbessert.

ADO.NET 2.0 bietet eine Vielzahl neuer Funktionen. Dazu gehören ein neues Provider-Modell (Managed Provider mit Server-Auflistung) auf der Grundlage von Basisklassen, Funktionen, die für alle Provider verwendet werden können, sowie Änderungen am System.Data.SqlClient. Weiterhin neu sind die enge Verbindung zum SQL Server 2005 und dessen Neuheiten sowie der verbesserte Umgang mit XML-Daten.

Das neue Provider-Modell in ADO.NET 2.0 basiert auf einer Reihe von Basisklassen in System.Data.Common. Diese bieten grundlegende Implementierungen allgemeiner Funktionen und verfügen natürlich über die für die Abwärtskompatibilität immer noch erforderliche allgemeine Schnittstelle. Entwickler von Providern können die Basisklassen verwenden oder die Schnittstellen unterstützen.

Auch bei den Basisklassen gibt es neue Funktionen. Die Basisklassen DataAdapter und DbDataAdapter zum Beispiel bieten Mechanismen für das Übergeben von Provider-spezifischen Typen wie SqlTypes von SQL Server an ein DataSet (die Eigenschaft ReturnProviderSpecificTypes) sowie für Batch-Aktualisierungen (den Enumerationswert StatementType.Batch und die Eigenschaft UpdateBatchSize). Die allgemeine Basisklasse DbCommandBuilder enthält die Eigenschaft ConflictDetection, die Auswahlrichtlinien bei Konflikten angeben kann.

Ein weiterer Schwerpunkt: ADO.NET 2.0 unterstützt die Neuerungen von SQL Server 2005. Dazu zählen etwa die automatische Mitteilung, wenn Daten in der Datenbank geändert wurden (Query Notifications), oder die Multiple Active Result Sets (MARS). MARS erlauben es, pro Datenbankverbindung mehrere Abfragen durchzuführen und verschiedene Resultsets im Speicher zu halten. Weiterhin bietet ADO.NET 2.0 einen verbesserten Umgang mit XML, da sich grundsätzlich alle Funktionen des DataSet jetzt auch auf XML-Dokumente anwenden lassen. Umgekehrt kann der Entwickler mit XML-Views ein Mapping auf relationale Daten erstellen, die sich dann genauso wie ein XML-Dokument anzeigen und bearbeiten lassen.

Developer Center zu ADO.NET 2.0
Auf der englischsprachigen MSDN-Webseite von Microsoft gibt es im Developer Center „Data Access and Storage“ eine Unterseite zu ADO.NET 2.0, die eine Reihe von technischen Artikeln rund um die neue Version der .NET-Datenzugriffs-Schnittstelle bietet.

ADO.NET 2.0: Featureübersicht
ADO.NET 2.0 umfasst ein neues Basisklassen-Provider-Modell, Funktionen für alle Provider und Änderungen am System.Data.SqlClient. In diesem Artikel erhalten Sie eine Übersicht über die neuen Features, Verwendungsbeispiele und ein Diagramm darüber, welche Features providerunabhängig und welche für SqlClient spezifisch sind. Basierend auf .NET Framework und Visual Studio 2005 Beta 1.

Datenzugriff mit ADO.NET 2.0
ADO.NET ist die zentrale Datenzugriffs-Schnittstelle für .NET-Anwendungen und Nachfolger der COM-basierten ActiveX Data Objects (ADO). ADO.NET gehörte zu den Teilen des .NET Framework 1.x, die zahlreichen Entwicklern nicht unerhebliche Umstellungsprobleme bereiteten, da es galt, sich auf das neue, verbindungslose Datenkonzept sowie auf das Fehlen einiger Funktionen einzustellen. Mit ADO.NET 2.0 legt Microsoft nun einige der vermissten Funktionen nach.

Änderungen im .NET Framework 2.0 Beta 2
In der Beta 2 des .NET Framework 2.0 hat Microsoft einige APIs gestrichen, darunter auch welche im Namenraum System.Data, der ADO.NET 2.0 betrifft. Betroffen sind vor allem die Bereiche System.Data.dll und System.Data.OracleClient.dll. Auf dieser Webseite finden Sie Informationen zu den gestrichenen APIs. In englischer Sprache.

Wichtige neue Funktionen

ADO.NET (Namensraum System.Data) gehört in den Versionen 1.0 und 1.1 zu den bei Entwicklern wenig beliebten Teile des .NET Frameworks, da einige Funktionen fehlen und die Vorgehensweise zum Teil recht ungewohnt oder gar umständlich ist. Mit ADO.NET 2.0 legt Microsoft nun zahlreiche vermisste Funktionen nach.

Provider Factories
ADO.NET 2.0 vereinfacht mit den Provider Factories die Möglichkeit, unabhängig vom Daten-Provider bzw. von einer konkreten Datenbank zu programmieren. Jeder Daten-Provider registriert in .NET eine ProviderFactory-Klasse und eine Provider-Zeichenfolge in der Datei machine.config. Die neue Basisklasse DbProviderFactory und die Klasse System.Data.Common.ProviderFactories können ein DataTable-Objekt mit Informationen über die verschiedenen, in machine.config registrierten Daten-Provider zurückgeben. Außerdem können Sie die richtige ProviderFactory anhand der Provider-Zeichenfolge (mit der Bezeichnung ProviderInvariantName) oder einer DataRow aus DataTable abrufen.

Server-Enumeration
Eine Bitmaske in machine.config legt fest, welche Basisklassen oder Basisschnittstellen ein Provider unterstützt. Dies ist notwendig, da nicht alle Provider alle Funktionen in System.Data.Common unterstützen müssen. Mit ADO.NET 2.0 kommt die neue Basisklasse DbEnumerator ins Spiel. Über diese Klasse können Provider, die diese Funktion unterstützen, eine Liste von Datenquellen abrufen. SqlClient unterstützt z. B. diese Klasse und gibt eine Liste der im Netzwerk verfügbaren Instanzen von SQL Server zurück. Dadurch wird Benutzern die Auswahl der Datenquelle ermöglicht.

Verbesserungen beim Verbindungs-Pooling
In ADO.NET 1.0 wurde eine neue Infrastruktur für das Pooling von Datenbankverbindungen eingeführt. Die Daten-Provider SqlClient und OracleClient von Microsoft verwenden diese Infrastruktur, die Daten-Provider OleDb und Odbc jedoch nicht. Der neue Pooling-Mechanismus von ADO.NET 2.0 unterstützt Parameter für das Verbindungs-Pooling mit einer hohen Granularität. Dazu gehören minimale und maximale Pool-Größen und die Möglichkeit für den Pool-Manager, eine benutzerdefinierte Zeit auf eine im Pool verfügbar werdende Verbindung zu warten.

Eine weitere Verbesserung sind Mechanismen, mit denen Sie programmgesteuert den Verbindungs-Pool leeren können, d. h. alle vom Pooler aktuell aufrecht erhaltenen Verbindungen lassen sich trennen. Sie können einen bestimmten Verbindungs-Pool mit der statischen Methode SqlConnection.ClearPool leeren oder alle Verbindungs-Pools in einer Anwendungsdomäne mit der Methode SqlConnection.ClearPools löschen. Sowohl SqlClient als auch OracleClient implementieren diese Funktion.

Connection String-Generator
Visual Studio .NET nutzte bislang eine OLE DB-Komponente für Connection Strings zum Darstellen von Datenquellen. Der OLE DB-Connection String-Generator listete die auf dem Computer installierten OLE DB-Provider auf, jedoch nicht die .NET-Daten-Provider. Der Entwickler kann dann einen Provider auswählen und einen ADO.NET-Connection String für den entsprechenden Provider erstellen.

In Visual Studio 2005 hingegen gibt die oben erwähnte Basisklasse DbProviderFactories eine Liste von .NET-Daten-Providern aus. Außerdem nutzt die Komponente für die Benutzeroberfläche nun die DbConnectionStringBuilder-Klasse, um Programmierern das grafische Erstellen eines Connection Strings und das Laden und Speichern von Connection Strings aus Konfigurationsdateien zu ermöglichen. .NET-Entwickler können diese oder eine davon abgeleitete Implementierung selbstverständlich auch nutzen.

Metadaten-API
Der Server-Explorer von Visual Studio 2005 ruft auch Metadaten zu Datenquellen wie beispielsweise Tabellen, Spalten, Ansichten und gespeicherte Prozeduren für die Anzeige ab. ADO.NET 2.0 stellt diese nützlichen Informationen mittels der neuen Schema-API zur Verfügung. Die ANSI SQL-Spezifikation verfügt über eine Basisspezifikation für diese Metadaten, die als INFORMATION_SCHEMA-Ansichten bezeichnet werden.

In ADO.NET 2.0 können Daten-Provider eine Konfigurationsdatei im XML-Format bereitstellen, in der die verfügbaren Metadaten und Verfahren für deren Abrufe aus der Datenbank aufgelistet werden, da bisher nicht alle Datenbanken die INFORMATION_SCHEMA-Ansichten unterstützen.

Ein Provider-Entwickler kann in ADO.NET 2.0 folgende fünf Metadaten-Typen offen legen, die in der Klasse System.Data.Common.DbMetaDataCollectionNames aufgelistet sind:

  • MetaDataCollections: Liste der verfügbaren Metadaten-Auflistungen. MetaDataCollections ist die Bezeichnung für die INFORMATION_SCHEMA-Auflistungen wie z. B. Tables, Columns oder PrimaryKeys.

  • Restrictions: Array mit Bezeichnern für jede Metadaten-Auflistung, mit denen der Umfang der angeforderten Schema-Informationen eingeschränkt werden kann.

  • DataSourceInformation: Informationen zur Datenbankinstanz, auf die der Daten-Provider verweist.

  • DataTypes: Satz mit Informationen zu jedem Datentyp, den die Datenbank unterstützt.

  • ReservedWords: Reservierte Wörter für die Abfragesprache der Datenbank. Die Abfragesprache ist meist ein SQL-Dialekt.

Ablaufverfolgung (Tracing)
Das Verfolgen von Aufrufen über die Datenbank-API ist sehr hilfreich, da man anhand einer Benutzerbeschreibung oder der Fehlermeldung eines Programms ermitteln kann, an welcher Stelle ein Problem mit dem Datenzugriffsstapel aufgetreten ist. Ursachen für diese Probleme sind meist falsche SQL-Anweisungen, eine falsche Programmierlogik, eine nicht verfügbare Datenbank, Probleme mit der Netzwerkbibliothek oder eine fehlende Schema-Übereinstimmung zwischen Client-Programm und Datenbank.

In der Vergangenheit war der Code für das Zulassen der Ablaufverfolgung Aufgabe des jeweiligen Providerentwicklers, obwohl es in einigen APIs wie ODBC auch De-facto-Standards gab. Das Fehlen einer Standard-OLE DB-Ablaufverfolgung erschwerte das Lösen von Problemen mit OLE DB und ADO. Obwohl diese Architektur nicht auf ADO.NET beschränkt ist, nutzen Microsoft-Provider in ADO.NET 2.0 die Vorteile verallgemeinerter Ablaufverfolgungs- und Instrumentierungs-APIs.

Durch die neuen Funktionen können Entwickler ein Problem auf jeder Ebene des Anwendungsstapels verfolgen. Nicht nur Microsoft ADO.NET-Provider, sondern auch andere Teile des Datenzugriffsstapels verwenden diese Funktionalität. Außerdem kann jeder Provider-Entwickler diese ebenfalls implementieren.

Verbesserungen beim SqlClient
SqlClient ist der Client-seitige Provider für SQL Server. ADO.NET 2.0 liefert zusätzlich mit OracleClient, OleDb und Odbc noch drei weitere Managed Provider. Diese vier Provider wurden erweitert, um sie in teilweise vertrauenswürdigen Umgebungen (Partial Trust) zu verwenden. Weitere Daten-Provider stammen von Datenbankfirmen (wie etwa ODP.NET von Oracle und der IBM-Daten-Provider für DB2), Provider-Spezialisten (DataDirect Technologies) sowie von Open Source-Projekten und Einzelpersonen.

In ADO.NET 2.0 gibt es wegen der enormen Bedeutung des SQL Servers noch eine Reihe von Erweiterungen am SqlClient. Einige dieser Funktionen unterstützen jede Version von SQL Server, viele der neuen Funktionen sind jedoch für die Unterstützung der neuen Features in SQL Server 2005 vorgesehen. SQL Server 2005 unterstützt .NET-Code, der direkt auf dem Server ausgeführt wird, auf dem Server selbst gibt es ebenfalls Optimierungen beim Datenzugriff mithilfe des Providermodells. Eine große interne Änderung: Der SqlClient-Datenprovider in ADO.NET 2.0 verwendet die Microsoft Data Access Components (MDAC) nicht mehr. Außerdem wurde die Fehlerbehandlung innerhalb des Providers durch genauere Fehlermeldungen verbessert, insbesondere bei Netzwerkfehlern.

Provider-Statistik
SqlClient verfügt jetzt in der SqlConnection-Klasse über Instanzmethoden wie RetrieveStatistics(), mit der Sie Statistiken für die einzelnen Verbindungen abrufen können, die denen in der ODBC-API entsprechen. Da das Speichern und Abrufen dieser Statistiken einen zusätzlichen Aufwand darstellt, gibt es eine Eigenschaft, mit der das Sammeln von Statistiken aktiviert bzw. deaktiviert werden kann. In der Standardeinstellung ist diese Funktion deaktiviert. Außerdem gibt es eine Methode für das Zurücksetzen der Leistungsindikatoren.

Asynchrone Befehle
ADO.NET 2.0 erlaubt beim SqlClient jetzt die asynchrone Ausführung von Datenbankbefehlen, d.h. der Aufrufer ist während der Abarbeitung des Befehls nicht blockiert und kann selbst weiterarbeiten. Da die Ausführung von Datenbankbefehlen lange dauern kann, bietet SqlClient folgende integrierte SqlCommand-Methoden für die asynchrone Ausführung: BeginExecuteNonQuery, EndExecuteNonQuery, BeginExecuteReader, EndExecuteReader, BeginExecuteXmlReader und EndExecuteXmlReader.

Massenimport von Daten (Bulkcopy)
Viele Datenbankanwendungen können mit einer INSERT-Anweisung Zeilen schnell in großen Stapeln in SQL Server einfügen. Obwohl SQL Server hierfür Dienstprogramme anbietet, verwenden diese Anwendungen meist eine Datei als Eingabequelle.SqlClient enthält in ADO.NET 2.0 jetzt die neue SqlBulkCopy-Klasse. Diese Klasse soll nicht wie das Werkzeug bcp die Eingabe direkt von Dateien übernehmen und eine Dateiausgabe erstellen, sondern von einem Client schnell und effizient viele Zeilen in die Datenbank einfügen. SqlBulkCopy kann seine Eingaben von DataReaders und DataSets erhalten.

MSDN TV: Ein erster Blick auf ADO.NET 2.0
Dieser Beitrag von MSDN TV führt auf Basis der Beta 1 in die wichtigsten neuen Funktionen von ADO.NET 2.0 ein. In englischer Sprache.

Asynchrone Befehle in ADO.NET 2.0
Dieser englischsprachige Artikel bietet eine Einführung in die asynchrone Befehlsausführung, eine neue Funktion von ADO.NET 2.0, sowie die Szenarien, für die sie entwickelt wurde. Darüber hinaus gibt der Artikel Tipps für die Anwendung dieser Funktion.

Schemas in ADO.NET 2.0
In diesem Artikel erfahren Sie, welche erweiterte Unterstützung ADO.NET 2.0 für den Zugriff auf Metadaten in Datenquellen bietet.

Neue DataSet-Features in ADO.NET 2.0
ADO.NET 2.0 bringt einige Neuerungen beim DataSet und DataTable mit. Dieser englischsprachige Artikel beschreibt unter anderem die Leistungsverbesserung durch eine neue Index-Engine und die binäre Serialisierung oder geht auf die erweiterten Funktionen des DataReader ein.

Funktionen speziell für SQL Server 2005

ADO.NET 2.0 unterstützt im SqlClient die Neuerungen von SQL Server 2005. Hier die wichtigsten Punkte:

MARS (Multiple Active Result Sets)
MARS ermöglicht mehrere ausstehende Anforderungen pro Verbindung. Insbesondere kann es mehrere offene Standard-Resultsets pro Verbindung geben. Das MARS-Feature hebt die aktuelle Einschränkung auf, bei der ein offenes Standard-Resultset dem Treiber erst dann erlaubt, Anforderungen an den Server zu senden, wenn das gesamte Resultset verwendet wurde.

Im eigenen Code fasst man mehrere Resultsets zusammen, indem man mehrere Instanzen von SqlCommand über dieselbe Verbindung verwendet. Jeder SqlCommand kann durch Aufruf von Command.ExecuteReader einen SqlDataReader verwenden, wobei sich auch mehrere SqlDataReaders zusammen verwenden lassen. In ADO.NET 1.0 und 1.1 musste man einen SqlDataReader schließen, bevor man einen anderen verwenden konnte.

Query Notifications
Die beiden SqlClient-Klassen SqlDependency und SqlNotificationRequest sind in ADO.NET 2.0 für die Benachrichtigungen über Datenänderungen (Query Notifications) zuständig. Dabei meldet der Client gegenüber der Datenbank sein Interesse an einer bestimmten Datenmenge an. Ändert sich diese Menge, startet eine Ereignisbehandlungsroutine, so dass der Client weiß, dass er die Daten erneut abrufen muss.

SqlDependency bindet SqlNotificationRequest ein und gibt die Benachrichtigungsinformationen als ein .NET-Ereignis aus. Bei SqlNotificationRequest gibt es kein Ereignis, so dass Sie das Registrieren für die Benachrichtigung und das Sammeln der Informationen selbst durchführen müssen. Die meisten Programmierer verwenden SqlDependency.

Die Query Notifications-Funktion gab es bereits in SQL Server 2000, nicht jedoch die Klasse SqlDependency. Diese gibt es nur in SQL Server 2005 und ist dort vom SQL Server Service Broker abhängig. Dies ist ein neues Feature, das ein skalierbares Warteschlangensystem implementiert. Beim Verwenden von Service Broker und SQL Server 2005 müssen Sie für den Erhalt von Benachrichtigungen eine Verbindung zur Datenbank aufrechterhalten. SqlDependency verwendet entsprechend Ihrer Auswahl HTTP- oder TCP-Protokolle und benachrichtigt Sie bei Änderungen an den zugrunde liegenden Zeilen.

Client Failover
SQL Server 2005 bietet eine Hot Spare-Funktion für das Spiegeln von Datenbanken. Wenn eine SQL Server-Instanz fehlschlägt, werden die Aufgaben automatisch an den Reserve-Server übertragen. Dafür ist eine Instanz erforderlich, die den Failover überwacht. SqlClient in ADO.NET 2.0 unterstützt Client Failover ohne spezielle Programmierung in der Anwendung.

Verschiedene Datentypen
SQL Server 2005 unterstützt benutzerdefinierte Typen (User Defined Type UDT), einen systemeigenen XML-Datentyp und „MAX“-Datentypen für große Datenmengen, insbesondere die Transact SQL-Typen VARCHAR(MAX), NVARCHAR(MAX) und VARBINARY(MAX).

Benutzerdefinierte Typen und der systemeigene XML-Typ werden durch die Spezifikationen SQL:1999 und SQL:2003 definiert. Für diese Datentypen hat Microsoft im SqlClient im Namensraum System.Data.SqlTypes die neuen Klassen SqlUdt und SqlXml definiert sowie die SqlDbTypes-Enumeration eingeführt. Außerdem wurde IDataReader.GetValue so erweitert, dass die Rückgabe von benutzerdefinierten Typen als .NET-Objekttypen und die Rückgabe von XML als .NET-Zeichenfolge unterstützt wird.

Diese neuen SQL Server 2005-Typen werden in DataReaders unterstützt, die von SQL-SELECT-Anweisungen zurückgegeben werden, sowie als Parameter mit SqlParameter. Die spezielle Klasse SqlMetaData kann Informationen über erweiterte Eigenschaften dieser neuen Datentypen zurückgeben, z. B. die XML-Schemaauflistung, die einer streng typisierten XML-Spalte entspricht, oder den Datenbanknamen eines benutzerdefinierten Typs. Sie können diese Typen direkt vom Client aus, in allgemeinem Code und auch im DataSet verwenden.

Multiple Active Result Sets (MARS) in SQL Server 2005
Dieser Artikel beschreibt die Architektur und die Arbeitsweise von MARS (Multiple Active Result Sets) und zeigt Wege, wie eine Applikation davon profitieren kann. MARS ermöglicht mehrere ausstehende Anforderungen pro Verbindung. In englischer Sprache.

Feature SQL Server 2005
SQL Server 2005 (Codename Yukon) ändert die Welt der Datenbankentwicklung durch die enge Verknüpfung mit dem .NET Framework und die Integration von Standards wie XML. Dieses Feature zeigt auf Basis der Beta 2, welche neuen Funktionen und Erweiterungen SQL Server 2005 bietet.

Query Notifications in ADO.NET 2.0
Neu in ADO.NET 2.0 sind Klassen für Benachrichtigungen über Datenänderungen (Query Notifications). Dabei meldet der Client gegenüber der Datenbank sein Interesse an einer bestimmten Datenmenge an. Ändert sich diese Menge, startet eine Ereignisbehandlungs-Routine, so dass der Client weiß, dass er wieder diese Daten abrufen muss. In englischer Sprache.

XML in ADO.NET 2.0 und SQL Server 2005
SQL Server 2005 und ADO.NET 2.0 bieten bessere XML-Unterstützung. In diesem englischsprachigen Artikel erfahren Sie, wie die Zusammenarbeit von SQL Server 2005 und ADO.NET 2.0 den Umgang mit XML-Daten in Anwendungen erleichtert.


Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?