Eine kleine Geschichte der Transaktionen (2. Datenbankzugriff )
In diesem Blogpost möchte ich kurz die Möglichkeiten des Datenbankzugriffs in der chronologischen Reihenfolge ihres Erscheinens vorstellen, wobei ich mich im Wesentlichen auf den SQL Server konzentriere.
Als Microsoft 1989 die erste Version des SQL Servers veröffentlichte gab es nur eine Programmierschnittstelle die auch als “Call-Level” API bezeichnete DB-Library. Diese beinhaltete ca. 150 Funktionen für MS-DOS und OS/2 Konsole sowie für OS/2 und Windows GUI Applikationen. Außerdem gab es noch Embedded SQL for C oder die Kurzform ESQL for C. Dabei handelt es sich um einen Precompiler der es ermöglichte SQL Statements direkt im Source Code zu verwenden. Für andere Datenbanksysteme von anderen Herstellern gab es natürlich auch ähnliche APIs, aber eben jede API speziell für eine Datenbank.
1992 kam mit Open Database Connectivity kurz ODBC die erste Schnittstelle auf den Markt, wo man versucht hat die darunter liegende Datenbank zu abstrahieren. Es sollte damit möglich sein Programme zu schreiben die mit unterschiedlichen Datenbanksystemen arbeiten konnten. Dabei gab es noch die Unterscheidung ob der ODBC Zugriff über die proprietäre Datenbank API erfolgt oder über einen nativen ODBC Treiber. Außerdem gab es noch verschiedene Level ODBC Treibern, wobei das Level den Umfang der unterstützten Funktionen angibt. Die Level waren mit Core, Level 1 und Level 2 bezeichnet. ODBC wird auch heute noch in vielen Applikationen ausgiebig genutzt.
Als dann COM mit Visual Basic immer populärer wurde gab es eine Objektschicht über ODBC um auf Datenbanken zugreifen zu können. Da war zunächst Data Access Objects (DAO) und dann etwas später Remote Data Objects (RDO).
Die nächste Entwicklung war mit OLE DB eine Objektorientierte COM basierte Basistechnologie, die ODBC vollständig ersetzt. Auch gab es die Möglichkeit die OLE DB auf Basis der proprietären DB API zu implementieren oder einen nativen OLE DB Provider zu entwickeln. OLE DB war aber nur für Programmiersprachen ausgelegt, welche über Pointer verfügten also Wesentlichen C und C++, damit waren aber VB uns alle Scriptsprachen in Internetanwendungen ausgenommen. Dazu wurden dann die ActiveX Data Objects (ADO) entwickelt. Für C++ gab es in der Active Template Library (ATL) OLE DB Templates, die es dem C++ Programmierer etwas einfacher machten mit OLE DB auf Datenbanken zuzugreifen. Diese Methode des Datenbankzugriffs ist die älteste die in meine Sample verwendet wird, weil dies auch die schnellste Zugriffstechnologie war bevor .NET auf den Markt kam. Etwas später wurde noch ein OLE DB Provider für ODBC fertiggestellt, womit man dann auch Zugriff auf alle ODBC Datenquellen mit ADO oder OLE DB bekommen konnte. Im folgenden Bild ist auch noch ADO Multi-Dimensional (ADOMD) eingezeichnet, dabei handelt es sich um eine ADO Erweiterung für den Analysis Server den “Data Warehouse” Server im SQL Server. Heute sind diese Technologien und Komponenten zusammengefasst in den Microsoft Data Access Components (MDAC) oder den Windows Data Access Components (WDAC), und sind Teil des Windows SDK.
Als dann .NET im Jahre 2000 das Licht der Welt erblickte, war es wieder Zeit für eine neue .NET basierte Zugrifftechnologie. ADO.NET benutzt als Datenbankzugriffsschicht einen .NET Framework Provider. Microsoft lieferte einen nativen Provider für den SQL Server, sowie weitere Provider für OLE DB und ODBC. ADO.NET war so designed, dass man mit dieser Technologie konsequent auf Snapshots gesetzt hat, um so datenbankschonende Applikationen zu forcieren. Die Phiolosophie ist die. Datenbankverbindung so spät wie möglich öffnen, das SQL Statement abzusetzen und dann die Verbindung so früh wie möglich wieder zu schließen. Geöffnete Verbindungen verbleiben in einem “Connection Pool” und können so wiederverwendet werden ohne eine neue “teure” Verbindung zu öffnen.
ADO.NET hat dann natürlich auch Weiterentwicklungen erfahren und es gab auch einige Erweiterungen. Mit der Spracherweiterung Language Integrated Query (LINQ) gab es auch eine Implementierung für den SQL Server LINQ2SQL. Dies war wenn man so will der erste Ansatz für einen objektrelationalen Mapper für .NET. Genau dies stellt dann das Entity Framework dar, der intern wieder einen Entity Data Provider, der auf dem ADO.NET Data Provider aufsetzt, benutzt um alle Features nutzen zu können.
Mit der immer mehr voranschreitenden Nutzen der “Cloud” wurden auch andere Technologien immer wichtiger. Hier ist in erster Linie Representational State Transfer (REST) zu nennen. Im .NET Framework wurde die Windows Communication Foundation (WCF). Um die WCF Data Services (vorher bekannt als ADO.NET Data Services und Code Name “Astoria”) erweitert, um es einfach zu machen RESTful Services in .NET zu entwickeln.
Für die Zukunft wird wohl das REST basierte Open Data Protocol oder kurz OData immer wichtiger. Siehe auch https://www.odata.org .
Microsoft investiert in die Zukunft im Bereich Entity Framework und WCF Data Services. Für weitere Informationen hierzu gibt es diese beiden Links :
Wer das Ganze noch ausführlicher behandelt haben möchte kann dies in mit folgenden MSDN Artikel haben 
.
Dort wird auch noch ausführlich auf die Analysis Services eingegangen, die ich hier nicht mit abgehandelt habe.
Schöne Grüße
- Martin