ADO.NET-Architektur
Aktualisiert: November 2007
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 3.0 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 (ADO.NET) 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' (ADO.NET).
Das folgende Diagramm zeigt die Beziehung zwischen einem .NET Framework-Datenanbieter und einem DataSet.
ADO.NET-Architektur
.gif)
Auswählen eines "DataReader" oder eines "DataSet"
Die Entscheidung, ob Ihre Anwendung einen DataReader (siehe Abrufen von Daten mit einem 'DataReader' (ADO.NET)) oder ein DataSet (siehe 'DataSets', 'DataTables' und 'DataViews' (ADO.NET)) verwenden soll, sollten Sie von der gewünschten Funktionalität Ihrer Anwendung abhängig machen. 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 'DataSet' durch einen 'DataAdapter' (ADO.NET)), 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 mithilfe zwischengespeicherter Daten in einem DataSet-Objekt Abfragefunktionen und Typüberprüfung zur Kompilierzeit zur Verfügung. Dadurch können Abfragen in einer .NET Framework-Entwicklungsprache wie C# oder Visual Basic geschrieben werden. 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 konzeptionelles Modell verwendet wird. Jede Tabelle wird durch eine separate Klasse dargestellt, wodurch das Objektmodell eng mit dem relationalen Datenbankschema verbunden wird. LINQ to SQL übersetzt LINQ-Abfragen im Objektmodell 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 dazu finden Sie unter LINQ to SQL.
ADO.NET Entity Framework
Das ADO.NET Entity Framework wurde entwickelt, damit Entwickler Anwendungen für den Datenzugriff erstellen können, indem sie für ein konzeptionelles Anwendungsmodell statt für ein relationales Speicherschema programmieren. Ziel ist es, die Menge an Code und Verwaltungsaufwand zu verringern, die für datenorientierte Anwendungen erforderlich ist. Weitere Informationen finden Sie unter ADO.NET Entity Framework.
ADO.NET Data Services
Das ADO.NET Data Services-Framework wird verwendet, um Datendienste im Internet oder einem Intranet bereitzustellen. Die Daten werden gemäß der 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 ADO.NET Data Services Framework.
XML und ADO.NET
ADO.NET nutzt XML, um nicht verbundenen Zugriff auf Daten bereitzustellen. ADO.NET wurde Hand in Hand mit den XML-Klassen in .NET Framework entworfen. Beide sind Komponenten einer gemeinsamen Architektur.
ADO.NET und die XML-Klassen in .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 finden Sie unter XML-Dokumente und XML-Daten.