Datenzugriffstechnologien

Die meisten Anwendungen erfordern einen Zugriff auf Daten. Wenn Sie eine neue Anwendung erstellen, stehen Ihnen drei ausgezeichnete Möglichkeiten für den Datenzugriff zur Verfügung: ADO.NET, ADO und OLE DB. Wenn Sie den Datenzugriff bei einer bestehenden Anwendung ändern müssen, entscheiden Sie sich aus Gründen der leichteren Wartung möglicherweise dazu, in der Anwendung weiterhin die bisherige Datenzugriffstechnologie zu verwenden. Wenn Sie jedoch mit einem langen Lebenszyklus der Anwendung rechnen, sollten Sie sich stattdessen für den Einsatz von ADO.NET für verwaltete Anwendungen oder von ADO für systemeigene Anwendungen entscheiden. Auf lange Sicht reduzieren die neuen Datenzugriffsmethoden i. d. R. die Entwicklungszeiten, vereinfachen Code und bieten eine ausgezeichnete Leistung.

ADO.NET

ADO.NET ist die strategische Schnittstelle auf Anwendungsebene für die Bereitstellung von Datenzugriffsdiensten auf der Microsoft .NET-Plattform. Sie können ADO.NET für den Zugriff auf Datenquellen mit den neuen .NET Framework-Datenprovidern verwenden. Diese Datenprovider umfassen:

• .NET Framework-Datenprovider für SQL Server
• .NET Framework-Datenprovider für OLE DB
• .NET Framework-Datenprovider für ODBC
• .NET Framework-Datenprovider für Oracle

Diese Datenprovider unterstützen eine Vielzahl von Entwicklungsanforderungen, z. B. Geschäftsobjekte mittlerer Ebene, die aktive Verbindungen zu Daten in relationalen Datenbanken und anderen Speicherstrukturen verwenden.

ADO.NET wurde speziell für Webanwendungen auf Nachrichtenbasis entwickelt, ist aber durch seinen Funktionsumfang auch für andere Anwendungsarchitekturen gut geeignet. Durch Unterstützung eines lose verknüpften Datenzugriffs maximiert ADO.NET die gemeinsame Nutzung von Daten, indem die Anzahl aktiver Verbindungen mit der Datenbank verringert wird. Dadurch wird vermieden, dass sich mehrere Benutzer die begrenzten Ressourcen auf dem Datenbankserver teilen müssen.

ADO.NET unterstützt verschiedene Arten des Datenzugriffs. Das DataSet ist eine gute Wahl, wenn Ihre Webanwendung oder Ihr XML-Webdienst auf Daten verschiedener Quellen zugreifen oder mit anderen (lokalen oder fernen) Anwendungen zusammenarbeiten muss bzw. wenn sich durch das Speichern und Übermitteln von zwischengespeicherten Ergebnissen Vorteile ergeben. Neben dieser Möglichkeit unterstützt ADO.NET Datenbefehle und Datenleser, um auf direktem Wege mit der Datenquelle zu kommunizieren. Zu diesen direkten Datenbankoperationen, die Datenbefehle und -leser verwenden, gehören laufende Abfragen und gespeicherte Prozeduren, das Erstellen von Datenbankobjekten, die Durchführung direkter Aktualisierungen und das Löschen mit Hilfe von DDL-Befehlen.

ADO.NET maximiert die gemeinsame Nutzung von Daten durch die Unterstützung eines Persistenz- und Übertragungsformats auf XML-Basis für das grundlegende Objekt von verteilten ADO.NET-Anwendungen, das DataSet. Ein DataSet ist eine relationale Datenstruktur, die den Schreib- und Lesezugriff gestattet und mit Hilfe von XML serialisiert werden kann. ADO.NET-DataSets vereinfachen das Erstellen von Anwendungen, die einen lose verknüpften Datenaustausch zwischen Anwendungsebenen und mehreren Websites benötigen.

Da DataSets im XML-Format übermittelt werden, können zwei beliebige Komponenten Daten und XML-Schemas jeweils gemeinsam nutzen, um die relationale Struktur des DataSets festzulegen. Außerdem können DataSet-Objekte problemlos ohne Beschränkungen Firewalls passieren, da das Serialisierungsformat XML ist. DataSets können XML-Daten laden und darüber hinaus mit Daten, die von SQL Server und durch OLE DB verfügbar gemachten Datenquellen stammen, gefüllt bzw. von diesen geändert werden.

Ein Hauptmerkmal von Datasets besteht darin, dass Sie die Daten in einem lokalen Dataset auf zwei Arten manipulieren können:

• Als Tabellen in einer relationalen Datenbank   Ein Dataset kann eine Tabelle oder eine Auflistung von Tabellen enthalten. Eine wichtige Eigenschaft des Datasets ist, dass es die Beziehungen zwischen den in ihm enthaltenen Tabellen verfolgt und in dieser Hinsicht einem speicherinternen relationalen Datenspeicher entspricht.
• Als XML (eXtended Markup Language)-Strukturen   Auf Daten innerhalb eines DataSets kann wie auf XML-Daten zugegriffen werden. Es stehen Methoden zur Verfügung, mit denen Daten im XML-Format bzw. die Struktur des DataSets als XML-Schema gelesen und geschrieben werden können. Des Weiteren kann ein XmlDataDocument einem DataSet zugeordnet werden; dies ermöglicht gleichzeitiges Anzeigen, Abfragen und Ändern von Daten im XML-Format.

Ausführliche Informationen zu den Anwendungsgebieten der ADO.NET-Datenzugriffstechnologie finden Sie in den Empfehlungen im Abschnitt Entscheidungshilfediagramm sowie in den folgenden Abschnitten: Einführung in verteilte Anwendungen und Datenintegration, Empfehlungen zur Zugriffsstrategie auf Webdaten, Übersicht über ADO.NET, Zugreifen auf Daten mit ADO.NET, ADO.NET-DataSets, Direktes Durchführen von Datenbankoperationen, Erstellen und Verwenden von DataSets.

ADO

Für Anwendungen, die in systemeigenem Code geschrieben werden, stellt ADO eine COM-basierte Schnittstelle auf Anwendungsebene für OLE DB-Datenprovider zur Verfügung. Ähnlich wie ADO.NET unterstützt ADO eine Reihe von Entwicklungsanforderungen, z. B. das Erstellen von Front-End-Datenbankclients und Geschäftsobjekten mittlerer Ebene unter Verwendung aktiver Verbindungen zu Daten in relationalen Datenbanken und anderen Speicherstrukturen. Ebenso wie ADO.NET erlaubt ADO außerdem das Erstellen clientseitiger Recordsets, die Verwendung lose verknüpfter Recordsets und die Verarbeitung von OLE DB-Rowsets für die Datenstrukturierung.

ADO unterstützt jedoch auch einige Funktionen, die unter ADO.NET nicht verfügbar sind, z. B. bildlauffähige serverseitige Cursor. Die Verwendung von serverseitigen Cursorn kann jedoch die Leistung und Skalierbarkeit einer Anwendung nachhaltig negativ beeinflussen, weil sie die Reservierung von Datenbankressourcen erforderlich macht. Um ADO-Recordsets über Firewalls hinweg zu übertragen, müssen Sie unter Beachtung der Sicherheitsauswirkungen die COM-Marshalling-Anfrage für den Firewall aktivieren. Darüber hinaus sind beim COM-Marshalling nur die im COM-Standard definierten Datentypen zulässig. Wahlweise können Sie ein ADO-Recordset im XML-Format speichern und stattdessen den XML-Text übertragen.

Weitere Informationen zu COM-Datentypen finden Sie unter COM-Datentypen. Weitere Informationen zu ADO finden Sie unter Einsatzbereiche von ADO und Programmieren von ADO-SQL Server-Anwendungen.

OLE DB

OLE DB ist die strategische Programmierschnittstelle auf Systemebene für den Datenzugriff und stellt die Basistechnologie für ADO sowie die Datenquelle für ADO.NET dar. OLE DB ist ein offener Standard für den Zugriff auf Daten aller Art, sowohl relationale als auch nicht relationale. Zu diesen Daten gehören u. a. Mainframe ISAM/VSAM-Datenbanken und hierarchische Datenbanken, Speicherstrukturen für E-Mails und Dateisysteme, grafische, geografische und Textdaten sowie benutzerdefinierte Geschäftsobjekte.

OLE DB stellt konsistenten und leistungsstarken Datenzugriff bereit und unterstützt eine Vielzahl von Entwicklungsanforderungen, z. B. das Erstellen von Front-End-Datenbankclients und Geschäftsobjekten mittlerer Ebene unter Verwendung aktiver Verbindungen mit Daten in relationalen Datenbanken und anderen Speichern.

Weitere Informationen zu OLE DB finden Sie auf der Microsoft OLE DB-Website (http://www.microsoft.com/data/oledb, nur auf Englisch verfügbar).

ADO.NET und ADO im Vergleich

Sowohl ADO.NET als auch ADO sind leicht zu programmieren und sprachunabhängig, stellen bei der Implementierung nur geringe Anforderungen an das System, belasten das Netzwerk minimal und benötigen nur wenige Schichten zwischen dem Front-End der Anwendung und der Datenquelle. Beide Methoden bieten einen Datenzugriff mit hoher Leistung.

Die Auswahl einer dieser beiden Methoden für den Datenzugriff beeinflusst Entwurf, Erweiterbarkeit, Interoperabilität und Verwaltungsaufwand einer Anwendung sowie eine Reihe weiterer Faktoren. Dazu gehören:

• Verwalteter Code   Wenn die Anwendung in verwaltetem Code geschrieben wird und auf der Common Language Runtime aufbaut, sollten Sie ADO.NET einsetzen. ADO ist eine gute Wahl, wenn Sie nicht verwalteten Code in C++ schreiben, insbesondere, wenn Sie eine bestehende ADO-Anwendung verwalten.
• Datenstruktur   Das ADO.NET-Dataset kann eine oder mehrere Tabellen enthalten und stellt sowohl eine relationale Ansicht auf Tabellenbasis als auch eine XML-Ansicht bereit. Das DataSet verwendet die Standardtypen der Common Language Runtime, was den Programmierprozess erheblich vereinfacht.

  Das ADO-Recordset besteht aus einer einzelnen Tabelle, auf die nur als Recordset zugegriffen werden kann und die keine Beziehungen enthält. Ein ADO-Recordset kann als Ergebnis einer JOIN-Abfrage für mehrere Tabellen entstanden sein, besteht jedoch immer aus einer einzigen Ergebnistabelle. Mehrere Tabellen erhalten Sie mit ADO nur, wenn Sie auch mehrere Recordset-Objekte verwenden. Das ADO.NET-Dataset bietet aufgrund der integrierten relationalen Struktur einen besseren Funktionsumfang.

• Gemeinsame Nutzung von Daten   ADO.NET bildet die Grundlage für den Datenaustausch zwischen Komponenten und verschiedenen Ebenen: DataSets können über das Internet und über Firewalls hinweg im XML-Format übermittelt werden. Sie können sich denselben Datensatz in der einen Anwendung als relationale Tabellen und in einer anderen Anwendung als XML-Datenstruktur anzeigen lassen. Das Dataset stellt eine bequeme bidirektionale Umwandlungsmethode von Dataset-Tabellen in ein XML-Dokument und umgekehrt bereit.

  Wenn Sie für die Übertragung eines ADO-Recordsets COM-Marshalling verwenden, muss die Zielanwendung für die Verwendung der Recordset-Datenstruktur programmiert sein. Dies erfordert einen größeren Programmieraufwand als das Lesen von XML-Daten. Sie können das ADO-Recordset auch als XML speichern. Die Daten lassen sich dann einfacher für andere Anwendungen und Dienste freigeben.

• Skalierbarkeit   Die Skalierbarkeit von ADO.NET ist unübertroffen. ADO.NET wurde von Grund auf eigens dafür entwickelt, die beste Datenzugriffsarchitektur für das Erstellen skalierbarer Webanwendungen bei gleichzeitig niedrigen Gesamtkosten zu bieten. Falls Sie auf Skalierbarkeit keinen Wert legen und Ihre Anwendungen nicht in verwaltetem Code schreiben, können Sie problemlos weiterhin ADO verwenden.
• Cursorplatzierung   Ergebnisgruppen können von einer Anwendung an zwei Stellen erzeugt werden: innerhalb des Anwendungsprozesses (clientseitiger Cursor) oder innerhalb des Datenspeicherungsprozesses (serverseitiger Cursor). Clientseitige Cursor bieten sich i. d. R. für alle Arten des spontanen Datenzugriffs durch Benutzer an. In ADO.NET werden clientseitige Cursor vom DataSet-Objekt, in ADO vom RecordSet-Objekt unterstützt.

  Sequenzielle, schreibgeschützte Servercursor werden in ADO.NET von Datenlesern (z. B. dem SqlDataReader-Objekt oder dem OleDbDataReader-Objekt) und in ADO von schreibgeschützten RecordSet-Objekten in Vorwärtsrichtung unterstützt. Demzufolge ist die Verwendung von sequenziellen, schreibgeschützten Cursorn die schnellste Methode, Daten aus einer Datenbank auszulesen.

  Bildlauffähige, aktualisierbare serverseitige Cursor werden in ADO von einem bildlauffähigen, aktualisierbaren RecordSet-Objekt unterstützt. Serverseitige Cursor sollten mit Bedacht eingesetzt werden. Beim nicht sequenziellen Bildlauf und Aktualisieren von Ergebnissen über einen serverseitigen Cursor treten Sperren und Ressourcenkonflikte auf, die die Skalierbarkeit der Anwendung erheblich beeinträchtigen. Anstelle eines scrollbaren und aktualisierbaren serverseitigen Cursors empfiehlt sich für das Verarbeiten von Ergebnissen auf dem Server die Verwendung gespeicherter Prozeduren.

• Datenzugriffsverbindung   Sowohl ADO.NET als auch ADO unterstützen explizite Verbindungen zur Datenbank. In ADO.NET können Entwickler einen Datenleser verwenden, der auf Grundlage der aktuellen Position Sperrungen vornimmt und eine kontinuierliche Verbindung mit der Datenbank erfordert, bis die Daten komplett gelesen wurden. Stattdessen können die Daten auch zu einem DataSet zusammengefasst werden. Bei der Verwendung eines DataSets ist es dem Entwickler freigestellt, ob er die Verbindung und Übermittlung während der Änderung der Daten im DataSet aufrechterhält oder diese nur einrichtet, wenn Daten in das DataSet eingetragen oder Aktualisierungen an die Datenbank übermittelt werden müssen. Das Aufheben der Verbindung gibt Ressourcen frei und richtet für andere Benutzer eine Sperre ein, während das DataSet geöffnet ist oder übermittelt bzw. bearbeitet wird. In ADO können Recordsets eine bestehende Verbindung verwenden und Sperren einrichten, während der Benutzer die Daten in der Datenbank betrachtet. Ein Clientcursor-Recordset kann jedoch auch ohne eine Datenbankverbindung mit den Daten arbeiten.
• Datenbildlauf   Sowohl in ADO.NET als auch in ADO kann ein sequenzieller oder nicht sequenzieller Bildlauf durch Daten durchgeführt werden. Außerdem können Sie mit dem ADO.NET-DataSet bequem von einer Zeile in einer Datentabelle zu den verknüpften Zeilen in einer anderen Tabelle wechseln. Sowohl das ADO-Recordset als auch die ADO.NET-Datenleser unterstützen sehr schnelle, schreibgeschützte serverseitige Vorwärtscursor. Nur das ADO-Recordset unterstützt bildlauffähige, aktualisierbare serverseitige Cursor, obwohl diese die Serverressourcen stark beanspruchen und in den meisten Fällen eher als Logik in gespeicherten Prozeduren oder optional als lose verknüpfte clientseitige Cursor implementiert werden sollten.
• Benutzerfreundlichkeit   ADO.NET-DataSets stellen selbstbeschreibende Daten bereit. Es ist nicht mehr erforderlich, die zugrunde liegenden Datenkonstrukte (z. B. Tabellen, Spalten, Zeilen oder Einschränkungen) zu verarbeiten. Stattdessen bietet Ihnen das DataSet typsicheren Zugriff auf Objekte, die Daten verwenden. Dies vereinfacht das Lesen, Schreiben und Ändern von Programmen. Da Anwendungsebenen Daten über XML-formatierte Datasets austauschen können, wird die Implementierung neuer und erweiterter Übertragungsmethoden innerhalb des Lebenszyklus der Anwendung vereinfacht. Bei ADO.NET ist es unerheblich, welche Sprache Sie für den Datenzugriff verwenden. Alle verwenden eine ähnliche Syntax sowie dieselben Dienste der Common Language Runtime.

  Obwohl ADO.NET ebenso wie ADO einen lose verknüpften Datenzugriff unterstützt, gibt es einen Unterschied. Mit ADO.NET können Sie kontrollieren, wie die Änderungen am DataSet an die Datenbank übertragen werden. Dies kann durch Ändern der vom DataAdapter-Objekt verwendeten Anweisungen geschehen oder durch Einfügen von benutzerdefiniertem Code, der auf Ereignisse zum Aktualisieren von Zeilen reagiert. Mit Hilfe dieser Funktion können Sie die Leistung optimieren, Gültigkeitsprüfungen ändern oder zusätzliche Verarbeitungsschritte einbinden, ohne dass Änderungen der Anwendung erforderlich werden. Weitere Informationen finden Sie unter Hinweise zur .NET-Anwendungsarchitektur.

Einsatz von OLE DB

Die Verwendung von OLE DB sollte wohl überlegt werden, da ADO.NET und ADO einfachere Methoden für den Datenzugriff bieten. Bei Ihrer Entscheidung, den OLE DB-Datenzugriff auf COM-Ebene zu verwenden, sollten Sie folgende Faktoren berücksichtigen:

• Leistung   ADO.NET und ADO sind äußerst schnell, fügen jedoch beim Arbeiten mit OLE DB-Datenquellen eine zusätzliche Abstraktionsschicht zwischen der Anwendung und dem Datenprovider ein. Wenn Sie Microsoft SQL Server als Back-End-Datenbank verwenden und verwalteten Code schreiben, empfiehlt sich die Verwendung des .NET Framework-Datenproviders für SQL Server, da hierdurch der größere Verarbeitungsaufwand in ADO und OLE DB umgangen wird und die Kommunikation mit dem Server direkt über den Netzwerktreiber erfolgt. Wenn Sie sich aus Leistungsgründen gegen eine SQL Server-Datenbank entscheiden, empfiehlt sich ggf. eine Programmierung in Visual C++ mit OLE DB. Datenprovider von Drittanbietern bieten Ihnen u. U. zusätzliche Möglichkeiten.
• Funktionalität   OLE DB legt fest, dass systemeigene Schnittstellen so umfangreich und erweiterbar sein müssen, dass die gesamte einer Datenbank zugrundeliegende Semantik und Funktionalität erkennbar ist. ADO verfügt über einen Teil der allgemeinen Funktionalität, die von den OLE DB-Schnittstellen definiert wird. ADO.NET stellt allgemeine Objekte für die Arbeit mit Daten zur Verfügung, die die Unterschiede in Verhalten, Funktionalität und Typsystematik verschiedener Quellen verbergen. Falls Sie auf systemeigenes Verhalten, Funktionalität oder Datentypen einer bestimmten Datenbank zugreifen müssen, bietet OLE DB die umfassendste systemeigene Schnittstelle mit der Datenquelle.
• Wartung   Die Verwendung der OLE DB-Datenzugriffstechnologie wirkt sich langfristig auf die Wartungskosten für die Anwendung aus. Die Verwendung von OLE DB ist kostenintensiver als die Verwendung von ADO.NET oder ADO, da die Wartung und Erweiterung des komplexen Programmcodes aufwendiger ist.
• Kenntnisse der Entwickler   Das Programmieren in der COM-Umgebung erfordert umfangreiche Programmierkenntnisse. Der Datenaustausch mit der OLE DB-Schnittstelle ist komplex und schwierig. Wenn Ihre Mitarbeiter mit OLE DB und COM vertraut sind, kann sich der Einsatz von OLE DB lohnen.
• Programmiersprache   Wenn Sie OLE DB für den Datenzugriff verwenden möchten, müssen Sie in Visual C++ programmieren. Mit Hilfe der Consumer- und Providervorlagen in der OLE DB-Vorlagenbibliothek kann die Programmierung etwas einfacher gestaltet werden. Weitere Informationen finden Sie unter OLE DB-Vorlagen.

Wenn die Anwendung die hohe Leistung und die direkten Zugriffsmöglichkeiten von OLE DB erfordert, Sie über die nötigen Kenntnisse für die Programmierung einer Schnittstelle auf Systemebene verfügen und längerfristig höhere Wartungskosten in Kauf nehmen, ist OLE DB die richtige Wahl.

Weitere Informationen zur Verwendung von OLE DB für den Datenzugriff finden Sie unter OLE DB-Programmierung.

Siehe auch

Zugreifen auf Daten mit ADO.NET | Einsatzbereiche von ADO | OLE DB-Programmierung