Vorteile von ADO.NET

Artikel
09/02/2008

Aktualisiert: November 2007

ADO.NET bietet gegenüber älteren Versionen von ADO und anderen Datenzugriffskomponenten mehrere Vorteile. Diese Vorteile können in die im Folgenden aufgeführten Kategorien eingeteilt werden.

Interoperabilität

ADO.NET-Anwendungen können die Flexibilität und die breite Akzeptanz von XML nutzen. Da XML das Format zur Übermittlung von Datasets über das Netz ist, können alle Komponenten, die das XML-Format lesen können, Daten verarbeiten. Tatsächlich muss die Komponente, die die Daten empfängt, selbst überhaupt keine ADO.NET-Komponente sein: Die Komponente, die die Daten sendet, kann das Dataset einfach an sein Ziel übertragen, ohne Rücksicht auf die Implementierung der Komponente nehmen zu müssen, die die Daten empfängt. Die Zielkomponente kann eine Visual Studio-Anwendung oder jede andere Anwendung sein, die mit einem beliebigen Tool implementiert wurde. Die einzige Voraussetzung ist, dass die Komponente, die die Daten empfängt, XML-Daten lesen kann. XML wurde als Industriestandard im Hinblick auf diese Art der Interoperabilität entwickelt.

Einfache Verwaltung

Während der Lebensdauer eines verteilten Systems sind kleine Änderungen möglich, umfangreiche Änderungen an der Architektur werden aber kaum vorgenommen, weil diese sehr komplex sind. Dies ist ungünstig, weil solche umfangreichen Änderungen von der Natur der Sache her erforderlich werden können. Wenn z. B. immer mehr Benutzer mit einer verteilten Anwendung arbeiten, könnte die erhöhte Belastung Änderungen an der Architektur erfordern. Mit zunehmender Beanspruchung des verteilten Anwendungsservers können die Systemressourcen knapp werden, und die Reaktionszeit oder der Durchsatz können darunter leiden. Angesichts dieses Problems können Softwareentwickler die Verarbeitung der Geschäftslogik auf der Serverseite und die Verarbeitung der Benutzeroberfläche auf separate Ebenen verteilen, die sich auf separaten Geräten befinden. Tatsächlich wird der Anwendungsserver durch zwei Ebenen ersetzt und das Problem der knappen Systemressourcen damit behoben.

Das Problem besteht nicht darin, eine Anwendung auf drei Ebenen zu entwerfen. Es besteht vielmehr darin, die Anzahl der Ebenen zu erhöhen, nachdem eine Anwendung verteilt wurde. Wenn die ursprüngliche Anwendung in ADO.NET mit Datasets implementiert ist, gestaltet sich diese Transformation einfacher. Denken Sie daran, dass Sie, wenn Sie eine einzelne Ebene durch zwei Ebenen ersetzen, für diese beiden Ebenen eine Lösung bereitstellen müssen, damit die Ebenen Informationen austauschen können. Da die Daten über XML-formatierte Datasets übertragen werden, ist die Kommunikation relativ einfach.

Programmierbarkeit

ADO.NET-Datenkomponenten in Visual Studio bieten eine Vielzahl an Datenzugriffsfunktionen, die Ihnen helfen, schneller und mit wenigern Fehlern zu programmieren. Beispielsweise abstrahieren Datenbefehle die Aufgabe für das Erstellen und Ausführen von SQL-Anweisungen oder gespeicherten Prozeduren.

Ähnlich ergeben durch die Designertools generierte ADO.NET-Datenklassen typisierte Datasets. Damit ist es Ihnen wiederum möglich, über eine typisierte Programmierung auf Daten zuzugreifen. Sehen Sie sich z. B. die folgende Zeile mit Code an, der auf einen Datenmember in einem nicht typisierten Dataset zugreift:

If totalCost > CType(dataSet1.Tables("Customers").Rows(n)("AvailableCredit"), Double) Then

if (totalCost > (double)dataSet1.Tables["Customers"].Rows[n]["AvailableCredit"])

Die entsprechende Zeile für den Zugriff auf einen Datenmember in einem typisierten Dataset sieht wie folgt aus:

If totalCost > dataSet2.Customers(n).AvailableCredit Then

if (totalCost > dataSet2.Customers[n].AvailableCredit)

Der Code für das typisierte Dataset lässt sich leichter lesen. Er lässt sich auch leichter schreiben, weil der Anweisungsabschluss bereitgestellt wird. "AvailableCredit" ist z. B. eine der Möglichkeiten, mit der die folgende Anweisung abgeschlossen werden kann:

If totalCost > dataSet2.Customers(n).

Letztlich ist der Code für das typisierte Dataset sicherer, weil er zur Kompilierungszeit eine Typüberprüfung ermöglicht. Angenommen, AvailableCredit wird als Währungsbetrag ausgedrückt. Wenn der Programmierer AvailableCredit fälschlicherweise eine Zeichenfolge zuordnet, würde die Umgebung den Fehler beim Kompilieren melden. Bei nicht typisierten Datasets würde der Programmierer erst zur Laufzeit von diesem Fehler erfahren.

Weitere Informationen zu typisierten und nicht typisierten Datasets finden Sie unter Übersicht über Datasets in Visual Studio.

Leistung

Für nicht verbundene Anwendungen bieten ADO.NET-Datasets Leistungsvorteile gegenüber nicht verbundenen ADO-Recordsets. Wenn COM-Marshalling zum Übertragen eines nicht verbundenen Recordsets zwischen den Ebenen verwendet wird, kann ein erheblicher Verarbeitungsaufwand entstehen, wenn die in den Recordsets enthaltenen Werte in von COM erkannte Datentypen konvertiert werden. In ADO.NET ist eine solche Konvertierung von Datentypen nicht erforderlich.

Skalierbarkeit

Da die Anforderungen an Ihre Daten durch das Web enorm steigen können, ist die Skalierbarkeit zu einem wichtigen Aspekt geworden. Internetanwendungen bieten ein unbegrenztes Potenzial an möglichen Benutzern. Wenn eine Anwendung ein Dutzend Benutzer gut versorgen kann, bedeutet dies noch lange nicht, dass sie Hunderte oder gar Hunderttausende von Benutzern genauso gut versorgen kann. Eine Anwendung, die Ressourcen (wie Datenbanksperren und Datenbankverbindungen) belegt, ist nicht in der Lage, eine Vielzahl von Benutzern gut zu versorgen, weil die Nachfrage der Benutzer nach diesen knappen Ressourcen schließlich das Angebot an Ressourcen übersteigt.

ADO.NET ermöglicht Skalierbarkeit, indem Programmierer beim sparsamen Umgang mit knappen Ressourcen unterstützt werden. Da jede ADO.NET-Anwendung einen nicht verbundenen Zugriff auf Daten einsetzt, werden keine Datenbanksperren oder aktiven Datenbankverbindungen über einen langen Zeitraum aufrecht erhalten.