Zitat von
Elvis:
Wenn man
ADO unabhängig von Delphis wrapper (dbGo) betrachtet, bekommt man fast die gleiche Hierarchie von Interfaces, die fast die gleichen Properties/Methoden haben, wie ihr
ADO.Net-Gegenstück.
ADO.Net wurde
wegen dieser Ähnlichkeit der Hierarchie so bennant. Hat ja nix mit
ActiveX zu tun.
1,
ADO ist default-maßig Connected.
ADO.NET arbeitet fast immer im Disconnected Modus.
2, In
ADO gibt man im Connection-String an welche Provider
ADO verwenden soll. In
ADO.NET muß ich auf jedenfall einen passenden managed
ADO.NET haben. D.h. in
ADO kann ich durch ändern des Connection-Strings (wenn die Anwendung einfach gestrickt ist) unterschiedliche
DBMS abfragen. In
ADO.NET brauch ich (wenn ich nicht nach
ADO "zurückfallen will" einen passenden
ADO.NET-Provider wobei M$ hier nur den für den MS
SQL-Server anbietet und eine (vermutlich kastrierten) für Oracle.
Das gewisse Ähnlichkeiten vorhanden sind ist zwangsweise gegeben. Diese sind aber auch zwischen DAO,
ADO, TDataset vorhanden.
Und mit meiner meinung über die unterschiede bin ich nicht allein. Siehe:
Eine Einführung in ADO.NET
Zitat:
Die Bezeichnung
ADO.NET für die Datenbankzugriffs-Architektur von .NET suggeriert Kontinuität. So ein bisschen wie
ADO 2.0 oder
ADO 2002. .NET wäre aber nicht .NET wenn Microsoft nicht auch hier tiefgreifend Hand angelegt hätte, so dass am Ende doch fast kein Stein auf dem anderen geblieben ist.