Die fehlende Object/Relation-Mapping-Technologie (ORM) war lange Zeit eine der grossen Schwächen im .NET-Framework. Nachdem man bei Microsoft das Bedürfnis nach einer ORM-Lösung in der Anfangsphase von .NET schlichtweg verschlafen oder ignoriert hat, unternahm man vor einigen Jahren mit ObjectSpaces und WinFS gleich zwei Anläufe in diesem Bereich. Mit beiden Ansätzen scheiterte der Branchenriese kläglich, und man musste in den Redmond-Labors praktisch wieder von vorne anfangen. Paradoxerweise bietet Microsoft inzwischen gleich zwei objektrelationale Mapper parallel an. Nachdem mit LINQ to SQL im Rahmen von Visual Studio 2008 (siehe InfoWeek 11/08) bereits eine relativ einfache ORM-Lösung für den SQL-Server eingeführt wurde, steht seit August mit dem Release des SP1 für das .NET-Framework 3.5 und Visual Studio 2008 nun mit dem ADO.NET Entity Framework (ADO.NET EF) eine umfangreichere und vor allem auch datenbankunabhängige objektrelationale Technologie bereit.
Ziel des objektrelationalen Daten-Mapping ist es, die unter Fachkreisen als Impedance Mismatch oder Semantic Gap genannte Problematik auszuräumen. Wer eine objektorientierte Programmiersprache einsetzt, möchte durchgängig mit Objekten arbeiten, auch dann wenn es um die Verarbeitung von Daten geht, welche in einer relationalen Datenbank gespeichert sind. Ziel dabei ist es, mit Geschäftsobjekten (auch Business Objects oder Geschäftsentitäten) zu arbeiten, die möglichst der Realität (Rechnung, Kunde, Artikel etc.) entsprechen. Das bringt gleich eine Reihe von Vorteilen mit sich: Mit Geschäftsobjekten lässt es sich aus programmiertechnischer Sicht – vor allem auch im Team – intuitiver arbeiten.
Ausserdem lassen sich n:m-Beziehungen einfacher abbilden und es kann auf typische objektorientierte Techniken wie die Vererbung zurückgegriffen werden.
Die Problematik dabei ist allerdings, dass Daten in der überwiegenden Zahl der verwendeten Datenbanken nicht in Form von Objekten, sondern normalisiert in relational verknüpften Tabellen abgelegt werden. Die Daten für eine Rechnung können beispielsweise über verschiedene Tabellen hinweg verteilt sein. Die Daten eines Objekts sind daher in den meisten Fällen nicht direkt auf die Tabellenstruktur übertragbar. Und genau hier kommt das objektrelationale Mapping ins Spiel: Es fungiert als Übersetzer zwischen relationalen Tabellen und den gewünschten Geschäftsobjekten.
Das ADO.NET Entity Framework setzt, wie sein Name bereits erahnen lässt, auf ADO.NET auf. Es erweitert die .NET-Datenzugriffstechnologie um eine weitere Abstraktionsschicht, welche die Kluft zwischen Tabellen und Geschäftsobjekten überwinden soll (siehe Diagramm «Die Architektur des ADO.NET Entity Framework»). Neben den Object Services, welche hauptsächlich für die Verwaltung der Geschäftsobjekte zuständig sind, kommt dem Entity Data Model (EDM) eine zentrale Rolle zu. Hier werden die Geschäftsklassen modelliert sowie das eigentliche Mapping zwischen den Objekten und den relationalen Datenstrukturen festgelegt (siehe Diagramm «Das Entity Data Model»). Das Entity Data Model setzt sich aus drei verschiedenen Modellen zusammen:
- Conceptual Model (DSDL): Im konzeptionellen Modell werden die Geschäftsentitäten und deren Beziehungen definiert, wie sie auf der Geschäftsebene der Anwendung benötigt werden. Eine eigentliche Verbindung zur physikalischen Struktur in der Datenbank existiert in diesem Modell nicht. Das konzeptionelle Modell unterstützt auch komplexe Datentypen und die Vererbung. Die Geschäftsobjekte werden vom Entity Framework auf Basis dieses Modells generiert.
Die verschiedenen Modelle im EDM werden ausschliesslich in XML beschrieben. Microsoft stellt allerdings Wizards und ein visuelles Modellierungswerkzeug (EF Designer) für Visual Studio 2008 zur Verfügung, mit deren Hilfe die Definitionen der drei Modelle relativ einfach von der Hand gehen. Dabei wird jeweils nach dem folgendem Schema vorgegangen: Ausgehend von einer Datenbank werden mit Hilfe eines Wizard die für das gewünschte Modell benötigten Tabellen, Views und Stored Procedures selektiert (siehe Bild 1).
Anschliessend generiert Visual Studio das konzeptionelle Modell. Nun kann man über den visuellen Designer Änderungen und Erweiterungen am Modell vornehmen (Bild 2). Alternativ kann auch mit einem leeren Modell gestartet werden. In diesem Fall müssen die Entitäten sowie die Mappings auf die Datenbanktabellen von Hand angelegt werden. Der entsprechende Source-Code für die Geschäftsklassen wird jeweils On-the-Fly in der entsprechenden Codebehind-Datei nachgetragen. Spätere Änderungen an der Datenbank können mit Hilfe eines Update Wizard im Modell aktualisiert werden, ohne dass dabei die bereits manuell durchgeführten Anpassungen überschrieben werden.
Mit dem Entity Client und den Object Services stellt das ADO.NET Entity Framework gleich zwei Schnittstellen für die Arbeit mit den im EDM gespeicherten Datenmodellen bereit. Der Entity Client (EntityClient) ist den Datenprovidern sehr ähnlich, die man bereits aus ADO.NET (z.B. SQLClient) kennt. So werden EntityClient-Abfragen beispielsweise ebenfalls mit einem Command-Objekt (EntityCommand) ausgeführt, das für die Verbindung zum EDM ein Connection-Objekt (EntityConnection) erfordert. Obwohl der Entity Client mit den Entitäten in EDM interagiert, werden keine Instanzen der Entitäten zurückgegeben. Statt dessen werden die Ergebnisse in Form eines DataReader-Objekts geliefert.
Da SQL nicht auf die Verarbeitung von Objekten ausgelegt ist, stellt der Entity Client eine spezielle SQL-Erweiterung mit der Bezeichnung Entity SQL (eSQL) zur Verfügung. eSQL ist speziell auf die Abfrage von im EDM gespeicherten Modellen optimiert. So kann zum Beispiel auf umständliche Joins verzichtet werden, da die Relationen zwischen den Entitäten ja bereits im Modell beschrieben sind.
Die volle ORM-Funktionalität kommt im ADO.NET Entity Framework erst bei der Verwendung der Object Services zum Tragen. Diese erlauben es, die im EDM definierten Entitäten in Form von instanzierten Geschäftsobjekten zu verwenden. Die Object Services sind zudem für die Persistierung der Business-Objekte verantwortlich und unterstützen dazu die typischen CRUD-Operationen (Create, Read, Update, Delete). Den für den Zugriff auf die Datenbank notwendigen SQL-Code wird dabei zur Laufzeit im Hintergrund dynamisch erzeugt.
Ausserdem stellen die Object Services weitere wichtige ORM-Mechanismen zur Verfügung. Dazu gehören etwa die Überwachung von Veränderungen an den Daten (so dass beispielsweise nur die Änderungen in die Datenbank zurückgeschrieben werden müssen), Identity Resolution oder das Concurrency Handling. Interessant an den Object Services ist, dass hier neben eSQL auch mit LINQ to Entities gearbeitet werden kann. Damit kommt man in den Genuss sämtlicher Vorteile von LINQ wie beispielsweise IntelliSense, lesbarerer Code oder eine Fehlerprüfung durch den Compiler.
Bei zwei gleichzeitigen O/R-Mappern aus demselben Haus drängt sich natürlich die Frage auf, wo die Unterschiede zwischen den beiden Lösungen liegen und welchen Mapper man für welchen Zweck einsetzen soll. Einer der gewichtigsten Unterschiede betrifft die Unterstützung der Datenbanken. Während bei LINQ to SQL ausschliesslich mit SQL Server ab Version 2000 (auch mit den Express-Editionen) gearbeitet werden kann, lässt das ADO.NET Entity Framework über ein offenes Providermodell die Einbindung von Datenbanksystemen anderer Anbieter zu. Neben Microsofts hauseigenem Provider für den SQL Server sind bereits Provider für Oracle, MySQL, SQLite, IBM DB2, PostgeSQL und einige andere Systeme erhältlich oder zumindest noch für dieses Jahr angekündigt.
Da LINQ to SQL direkt auf dem Datenbankschema aufsetzt und mit dem konzeptionellen Modell auf eine wesentliche Abstraktions-
ebene verzichtet wird, bietet das ADO.NET Entity Framework deutlich mehr Flexibilität beim Mapping und bei der Modellierung von Entities. Ein weiteres Manko von LINQ to SQL ist, dass Änderungen an den Datenbankstrukturen im generierten Modell nicht aktualisiert werden. Der Einsatz von LINQ to SQL macht deshalb vor allem in «einfacheren» Szenarien oder für RAD (Rapid Application Development) Sinn, wo die 1:1-Abbildung von Tabellen auf Klassen ausreicht.
Gegenüber LINQ-to-SQL bietet das ADO.NET Entity Framework einige Vorteile, wie beispielsweise das Abbilden von n:m-Relationen, die automatische Aktualisierung des Modells bei Änderungen am Datenbankschema oder der Verwendung von komplexen Datentypen und Vererbung. Wegen des grösseren Funktionsumfangs und der höheren Flexibilität eignet sich das Entity Framework eher für den Enterprise-Einsatz – vor allem auch dann, wenn ein späterer Wechsel der darunterliegenden Datenbank nicht auszuschliessen ist.
Die Architektur des ADO.NET Entity FramewoRks
In den letzten Monaten kam gegenüber dem ADO.NET Entity Framework immer wieder die Kritik auf, dass wichtige Aspekte einer ORM-Lösung gar nicht richtig umgesetzt würden. Vergangenen Juni hat sich gar eine Gruppe von Entwicklern zusammengerauft und eine Petition gestartet, mit der erreicht werden soll, dass Microsoft das Design des Entity Framework noch einmal gründlich überdenkt. Neben einer ganzen Reihe von technischen Details (z.B. das mangelhafte Lazy Loading) bemängelt die Gruppe vor allem die datenlastige Sichtweise des Framework.
Dies würde Domain-getriebenes Modellieren (Objects-first-Prinzip), bei dem primär auf ein optimales Design von Geschäftsobjekten und erst in einem zweiten Schritt auf das Design des Datenbankschemas geachtet wird, praktisch unmöglich machen. Ausserdem wird in der Petition die fehlende Unterstützung des EF-Designers für die Entwicklung in Teams oder die mangelhafte Umsetzung von Test-Driven-Design-Prinzipien moniert. Das ADO.NET-Team hat auf die Petition reagiert und versprochen, die Ausmerzung der angeführten Mängel für den nächsten Release in Betracht zu ziehen. Version 2.0 des ADO.NET Entity Framework wird allerdings erst gemeinsam mit Visual Studio 10 erscheinen, das vermutlich nicht vor Ende 2009 auf den Markt kommen wird.
Nach einigen Anlaufschwierigkeiten hat es Microsoft nun endlich geschafft, eine einigermassen solide ORM-Lösung für .NET zu liefern. Wie die breit abgestützte Kritik zeigt, handelt es sich beim ADO.NET Entity Framework um einen typischen 1.0-Release, der noch über einige Ecken und Kanten verfügt. Für Entwickler dürfte es sich trotzdem lohnen, sich bereits heute mit dem Entity Framework zu beschäftigen und für künftige Projekte in Betracht zu ziehen.
Denn mittel- bis längerfristig dürfte sich bei Microsoft das Entity Frame-
work als die bevorzugte ORM-Technologie – auch zugunsten von LINQ to SQL – durchsetzen. In Redmond scheint man grosse Pläne für den neuen Object Mapper zu haben und spricht davon, ADO.NET EF in künftigen Produkten wie zum Beispiel in den SQL Server zu integrieren.
