ADO.NET-Architektur

Die traditionelle Datenverarbeitung basierte primär auf einem verbindungsbasierten Modell mit zwei Ebenen. Da für die Datenverarbeitung immer mehr auf Architekturen mit mehreren Ebenen zurückgegriffen wird, wird verstärkt mit nicht verbundenen Lösungen gearbeitet, um eine bessere Skalierbarkeit der Anwendungen zu erzielen.

ADO.NET-Komponenten

Die beiden Hauptkomponenten von ADO.NET für den Zugriff auf und die Bearbeitung von Daten sind die .NET Framework-Datenanbieter und das DataSet.

.NET Framework-Datenanbieter

Die .NET Framework-Datenanbieter sind Komponenten, die explizit für die Datenbearbeitung und den schnellen, vorwärts gerichteten, schreibgeschützten Zugriff auf Daten entworfen wurden. Das Connection-Objekt sorgt für die Verbindung mit einer Datenquelle. Mit dem Command-Objekt können Sie auf Datenbankbefehle zugreifen, um Daten zurückzugeben oder zu ändern, gespeicherte Prozeduren auszuführen und Parameterinformationen zu senden oder abzurufen. Der DataReader sorgt dafür, dass die Daten mit maximaler Geschwindigkeit per Stream bereitgestellt werden. Der DataAdapter fungiert als Brücke zwischen dem DataSet-Objekt und der Datenquelle. Der DataAdapter verwendet zum Ausführen von SQL-Befehlen an der Datenquelle Command-Objekte, um damit sowohl Daten in das DataSet zu laden als auch um die Datenquelle mit den an den Daten im DataSet vorgenommenen Änderungen zu aktualisieren. Weitere Informationen finden Sie unter .NET Framework-Datenanbieter und Abrufen und Ändern von Daten in ADO.NET.

Das "DataSet"

Das ADO.NET-DataSet wurde explizit für den datenquellenunabhängigen Datenzugriff entwickelt. Aus diesem Grund kann es mit mehreren, unterschiedlichen Datenquellen, mit XML-Daten oder zum Verwalten von lokalen Anwendungsdaten verwendet werden. Das DataSet enthält eine Auflistung von einem oder mehreren DataTable-Objekten, die aus Datenzeilen und -spalten sowie aus Primärschlüsseln, Fremdschlüsseln, Einschränkungen und Beziehungsinformationen zu den in den DataTable-Objekten enthaltenen Daten bestehen. Weitere Informationen finden Sie unter DataSets, DataTables und DataViews.

Das folgende Diagramm zeigt die Beziehung zwischen einem .NET Framework-Datenanbieter und einem DataSet.

ADO.Net graphic
ADO.NET-Architektur

Auswählen eines "DataReader" oder eines "DataSet"

Bei der Entscheidung, ob Ihre Anwendung einen DataReader verwenden sollte (siehe Abrufen von Daten mit einem DataReader) oder ein DataSet (siehe DataSets, DataTables und DataViews), sollten Sie berücksichtigen, welche Funktionalität Ihre Anwendung erfordert. Ein DataSet sollten Sie für folgende Aufgaben verwenden:

  • Lokales Zwischenspeichern von Daten in Ihrer Anwendung, um sie bearbeiten zu können. Wenn die Ergebnisse einer Abfrage nur gelesen werden sollen, ist der DataReader die bessere Wahl.

  • Verschieben von Daten zwischen Ebenen oder von einem XML-Webdienst.

  • Dynamisches Interagieren mit Daten, wie Datenbindung an ein Windows Forms-Steuerelement, oder Kombinieren von und Erstellen einer Beziehung zwischen Daten aus mehreren Quellen.

  • Ausführen umfangreicher Datenverarbeitungsschritte ohne eine offene Verbindung zur Datenquelle. Dadurch wird die Verbindung zur Nutzung durch andere Clients freigegeben.

Wenn Sie die vom DataSet bereitgestellte Funktionalität nicht benötigen, können Sie die Geschwindigkeit Ihrer Anwendung verbessern, indem Sie den DataReader verwenden, der Ihre Daten vorwärts gerichtet und schreibgeschützt zurückgibt. Obwohl der DataAdapter zum Füllen des DataSet-Inhalts den DataReader verwendet (siehe Auffüllen eines „DataSets“ durch einen „DataAdapter“), können Sie durch die Verwendung des DataReader die Geschwindigkeit der Anwendung erhöhen, da Sie auf diese Weise Arbeitsspeicher sparen, der anderenfalls vom DataSet beansprucht worden wäre. Außerdem entfällt der Verarbeitungsaufwand für das Erstellen und Füllen des DataSet.

LINQ to DataSet

LINQ to DataSet stellt Abfragefunktionen und Typüberprüfungsfunktionen zur Kompilierzeit über die in einem DataSet-Objekt zwischengespeicherten Daten bereit. Sie können damit Abfragen in einer der .NET Framework-Entwicklungssprachen schreiben, z. B. in C# oder Visual Basic. Weitere Informationen finden Sie unter LINQ to DataSet.

LINQ to SQL

LINQ to SQL unterstützt Abfragen für ein Objektmodell, das den Datenstrukturen einer relationalen Datenbank zugeordnet ist, ohne dass ein vorläufiges Konzeptmodell verwendet wird. Jede Tabelle wird durch eine separate Klasse dargestellt, wodurch das Objektmodell eng mit dem relationalen Datenbankschema verbunden wird. LINQ to SQL übersetzt im Objektmodell vorhandene LINQ-Abfragen in Transact-SQL und sendet diese zur Ausführung an die Datenbank. Wenn die Datenbank die Ergebnisse zurückgibt, übersetzt LINQ to SQL die Ergebnisse zurück in Objekte. Weitere Informationen finden Sie unter LINQ to SQL.

ADO.NET Entity Framework

Das ADO.NET Entity Framework wurde entworfen, um Entwicklern die Möglichkeit zu geben, Anwendungen für den Datenzugriff zu erstellen, indem sie bei der Programmierung auf ein konzeptionelles Anwendungsmodell zugreifen können, anstatt direkt mit einem relationalen Speicherschema zu arbeiten. Das Ziel ist es, die Menge des Codes und den Wartungsaufwand zu verringern, die für datenorientierte Anwendungen erforderlich sind. Weitere Informationen finden Sie unter ADO.NET Entity Framework.

WCF Data Services

WCF Data Services wird verwendet, um Datendienste im Internet oder in einem Intranet bereitzustellen. Die Daten werden gemäß den Spezifikationen des Entity Data Model in Entitäten und Beziehungen strukturiert. Die in diesem Modell bereitgestellten Daten sind durch das Standard-HTTP-Protokoll adressierbar. Weitere Informationen finden Sie unter WCF Data Services 4.5.

XML und ADO.NET

ADO.NET nutzt die Funktionen von XML, um Datenzugriff bei getrennter Verbindung zu ermöglichen. ADO.NET wurde gemeinsam mit den XML-Klassen in .NET Framework entworfen. Beide sind Komponenten derselben Architektur.

ADO.NET und die XML-Klassen im .NET Framework konvergieren im DataSet-Objekt. Das DataSet kann mit Daten aus einer XML-Quelle gefüllt werden, gleich, ob es sich dabei um eine Datei oder um einen XML-Stream handelt. Das DataSet kann als W3C-konformer XML-Code geschrieben werden, dessen Schema als XSD-Schema (XML Schema Definition Language) ausgeführt ist. Die Quelle der Daten im DataSet spielt dabei keine Rolle. Da das systemeigene Serialisierungsformat des DataSet XML ist, handelt es sich um ein hervorragendes Medium zum Verschieben von Daten zwischen den Ebenen der Architektur. Somit ist das DataSet eine optimale Wahl für das Remoting von Daten und Schemakontext zu und von einem XML-Webdienst. Weitere Informationen hierzu finden Sie unter XML Documents and Data (XML-Dokumente und -Daten).

Siehe auch