Mit Ausnahme des Open-Source- Projekts NHibernate [2] sitzen die Anbieter im deutschsprachigen Raum. Was ist ORM?

Transkript

1 Tools Objektrelationale Mapper für.net im Vergleich Die Qual der Wahl Während sich die Programmierung schon lange dem objektorientierten Paradigma verschrieben hat, bewährt sich beim Speichern von Daten nach wie vor die relationale Methode. Objektrelationale Mapper verbinden beide Welten. Dr. Holger Schwichtenberg vergleicht LINQ-to-SQL mit dem ADO.NET Entity Framework, NHibernate, Vanatec Open Access, NDO und Genome. In der Java-Welt gehört das objektrelationale Mapping (ORM) schon lange zu den etablierten Techniken. Microsoft hat diesen Trend lange verschlafen und es nicht vermocht, ein geeignetes Produkt zur Marktreife zu führen. ADO.NET in.net 1.0 bis 3.5 enthält kei- Auf einen Blick Autor Dr. Holger Schwichtenberg gehört als Autor zahlreicher Fachbücher und Sprecher auf Fachkonferenzen zu den Experten für.net und Visual Studio in Deutschland. Im Hauptberuf berät und unterstützt er Unternehmen bei der Entwicklung von Windows- und Web - anwendungen. Seine Website bietet kostenlose Informationen rund um.net. dotnetpro.code A0804ORM Inhalt Objektrelationale Mapper bilden Geschäftsobjekte der objektorientierten Programmierung auf Tabellen und Felder relationaler Datenbanken ab. Herausforderungen dabei sind die Umsetzung von n:m-beziehungen zwischen Tabellen und die Vererbung zwischen Objekten. Auf dem Markt tummeln sich viele Anbieter von Werkzeugen. Microsoft verwirrt die Nutzer gleich mit zwei verschiedenen Ansätzen: LINQ-to-SQL und das ADO.NET Entity Framework, die jedoch auf unterschiedlichen Ebenen arbeiten. Abbildung 1 Die Positionierung verschiedener Datenbankzugriffsschnittstellen. nen ORM, sondern beschränkt sich auf den direkten Datenzugriff und die Abbildung zwischen XML-Dokumenten und dem relationalen Modell (Abbildung 1). Mehr als 20 Werkzeuge aus dem kommerziellen und nicht-kommerziellen Umfeld teilen sich daher bisher den Markt. Ein Vergleich zwischen allen ORM-Werkzeugen für.net würde den Rahmen eines Fachartikels völlig sprengen. Dieser Beitrag vergleicht daher die beiden Microsoft-Produkte LINQ-to-SQL und ADO.NET Entity Framework [1] mit einigen im deutsprachigen Bereich häufiger anzutreffenden Tools der Anbieter Vanatec Open Access (VOA), NDO und Genome. Mit Ausnahme des Open-Source- Projekts NHibernate [2] sitzen die Anbieter im deutschsprachigen Raum. Was ist ORM? In seinen Schulungen und Beratungsgesprächen trifft der Autor immer wieder auf.net-entwickler, die mit dem Begriff des objektrelationalen Mappings und seiner Abkürzung ORM nichts anfangen können. So sei der Begriff hier zunächst definiert: ORM ist die Abbildung von Geschäftsobjekten im Hauptspeicher auf Datensätze in relationalen Datenbanktabellen zum Zweck der Objektpersistenz (Abbildung 2). Kern des objektorientierten Programmierens (OOP) ist die Arbeit mit Objekten als Instanzen von Klassen im Hauptspeicher. Die meisten Anwendungen müssen die in Objekten gespeicherten Daten auch dauerhaft sichern, insbesondere in Datenbanken. Das Problem dabei: Der vorherrschende Typus von Datenbanken sind relationale Datenbanken, die jedoch Datenstrukturen anders abbilden als Objektmodelle. Die Daten eines Objekts sind in der Regel nicht direkt auf die Tabellenstruktur einer Datenbank übertragbar. Deshalb müssen sie auf diese übersetzt ge

2 ben will. Neben den aktiven Entwicklern von ORM-Werkzeugen für.net und den passiven Nutzern gibt es eine noch größere Fraktion von Entwicklern, die ORM bisher nicht einsetzen. Meist aufgrund von Unwissenheit, die auch nicht aufgearbeitet wird, denn es herrscht oft das Motto Wenn Microsoft es nicht macht, ist es auch nicht wichtig!. Abbildung 2 ORM bildet Objekte auf Datensätze ab und umgekehrt. mappt werden. Das ist die Aufgabe eines objektrelationalen Mappers. Grundsätzlich gibt es zwar objektorientierte Datenbanken (OODB), die in der Lage sind, Objekte direkt zu speichern. Aber diese Datenbanken sind bisher kaum verbreitet. Zwei besonders hervorstechende Unterschiede zwischen Objektmodell und Relationenmodell sind n:m-beziehungen und Vererbung. Während man in einem Objektmodell eine n:m-beziehung zwischen Objekten durch eine wechselseitige Objektmenge abbilden kann, benötigt man in der relationalen Datenbank eine Zwischentabelle. Vererbung kennen relationale Datenbanken gar nicht. Hier gibt es verschiedene Möglichkeiten der Nachbildung, doch dazu später mehr. Die unterschiedliche Art der Datenspeicherung zwischen Objektmodell und relationalem Modell bezeichnet die Fachwelt als Impedance Mismatch oder Semantic Gap. Wenn ein.net-entwickler aus einer Datenbank mit einem DataReader oder DataSet Daten einliest, dann betreibt er noch kein ORM. DataReader und DataSet sind zwar.net-objekte, aber diese verwalten nur Tabellenstrukturen. Diese Objekte sind aus der Sicht eines Objektmodells untypisierte, unspezifische Container. Erst wenn ein Entwickler spezifische Klassen für die in den Tabellen gespeicherten Strukturen definiert und die Inhalte aus DataSet oder DataReader in diese spezifischen Datenstrukturen umkopiert, betreibt er ORM. Dies ist schon für den Lesezugriff eine sehr aufwendige, mühselige und eintönige Programmierarbeit, gerade bei sehr breit angelegten Tabellen. Will der Entwickler dann auch noch Änderungen in den Objekten speichern, wird die Arbeit zur intellektuellen Herausforderung, denn er muss erkennen können, welche Objekte sich verändert haben, da er sonst ständig alle Daten wieder speichern müsste, was in Mehrbenutzerumgebungen ein Unding ist. Viele.NET-Programmierer haben sich in den letzten Jahren darum bemüht, diese Arbeit mit Hilfsbibliotheken und Werkzeugen zu vereinfachen. Dies war die Geburtsstunde vieler ORM-Tools, die im Entwicklerjargon in der Regel einfach als O/R-Mapper bezeichnet werden. Dabei scheinen sich viele Entwickler dem geflügelten Wort verschrieben zu haben, dass ein Mann in seinem Leben einen Baum gepflanzt, ein Kind gezeugt und ein Haus gebaut haben sollte nur mit dem Unterschied, dass sie einen der drei Punkte gegen einen O/R-Mapper geschrieben haben austauschten. Anders ist die Vielfalt der ähnlichen Lösungen kaum zu erklären. Neben den marktbekannten ORM- Werkzeugen für.net finden sich zahlreiche hauseigene Lösungen. Die große Vielfalt an Produkten führte bisher dazu, dass keiner der Anbieter eine überragende Marktposition einnehmen konnte. Der Autor dieses Beitrags kann sich hier selbst nicht aus der Affäre ziehen, denn auch er hat in der Vergangenheit einen eigenen O/R-Mapper geschrieben, den er aber nun zugunsten des ADO.NET Entity Frameworks aufge- Microsoft kommt erst jetzt Microsoft jedoch hat der Drang zur Veröffentlichung eines ORM-Werkzeugs lange nicht voll erfasst. Zwar gab es 2003 eine Alphaversion eines O/R-Mappers unter dem Codenamen ObjectSpaces, die auch in den ersten Vorabversionen von.net 2.0 enthalten war, aber leider hat es Object- Spaces nicht zur Marktreife geschafft. Die endgültige Version von.net 2.0 und 3.0 enthielten weder ObjectSpaces noch ein anderes ORM-Werkzeug. Der Grund für das Scheitern lag nicht nur im Lehrgeld, das Microsoft zahlen musste, sondern auch darin, dass damals im Rahmen des datenbankbasierten Dateisystems WinFS ein ähnliches Konzept parallel realisiert werden sollte. Das inzwischen vorerst beerdigte WinFS sollte nicht nur Dateien, E- Mails und Kontakte ablegen können, sondern auch beliebige andere.net-objekte. Zwei ähnliche Produkte ergaben damals Ein Wort zum Thema Geschwindigkeit Eine interessante Frage ist die nach der Geschwindigkeit der ORM-Werkzeuge. Aber aufgrund der vielen möglichen Szenarien würde dies den Rahmen dieses Beitrags völlig sprengen. Der Autor hat beim Datenlesen gemessen, dass LINQto-SQL etwa so schnell ist wie ein Data- Set; NHibernate und VOA brauchen hier mehr Zeit, was aufgrund der höheren Komplexität der Abbildung aber auch verständlich ist. Den DataReader kann natürlich kein ORM-Werkzeug schlagen, denn alle Werkzeuge benutzen ihn oder ein vergleichbares Konstrukt im Hintergrund. Viele Entwickler hegen das Vorurteil, dass ORM sehr langsam sei. Ihnen sei gesagt: Richtig ist, dass ORM langsamer ist als ein DataReader. Aber ein Windows-Fenster ist auch langsamer als ein Kommandozeilenfenster. Arbeiten Sie deshalb immer an der Kommandozeile?

3 Tools Objektrelationale Mapper für.net im Vergleich Abbildung 3 Abbildungsszenarien zwischen Klassen und Tabellen. aber nach Ansicht der Redmonder Chefetage keinen Sinn. Umso kurioser ist es, dass es nun doch wieder zwei O/R-Mapper von Microsoft für.net geben wird. Als Teil des.net Framework 3.5 ist im November 2007 LINQ-to-SQL erschienen, Mitte 2008 werden dann die ObjectServices im Rahmen des ADO.NET Entity Framework (EF) folgen. LINQ-to-SQL oder Entity Framework LINQ-to-SQL und die EF ObjectServices weisen trotz gewisser Ähnlichkeiten doch erhebliche Unterschiede auf. Die EF ObjectServices sind keineswegs die zweite Version von LINQ-to-SQL. Der Begriff LINQ-to-SQL vereint mehrere Konzepte, für die es beim ADO.NET Entity Framework unterschiedliche Bezeichnungen gibt. LINQ-to-SQL meint einerseits die Umsetzung der allgemeinen Abfragesprache LINQ [3] in die Datenbankabfragesprache SQL. Andererseits umfasst LINQ-to-SQL auch ORM, bildet also Tabellen auf Objekte ab. Beim ADO.NET Entity Framework sind diese Konzepte getrennt: LINQ-to-Entities ist die Abfragesprache, und die EF Object- Services vollbringen das objektrelationale Mapping. Hinzu kommt, dass LINQ-to- Entities nicht LINQ auf SQL abbildet, sondern LINQ auf Entity SQL (esql), eine SQL-ähnliche Sprache des Entity Frameworks [4]. Der Kern des EF ist die Abbildung physischer Datenstrukturen aus Tabellen in Datenbanken auf konzeptionelle Datenstrukturen, sogenannte Entitäten, wie man sie aus dem Entity-Relationship- Modell kennt. LINQ-to-Entities arbeitet auf den Entitäten; und Entitäten werden auf Objekte abgebildet. Eine n:m-zwischentabelle wird hier also schon eine Ebene tiefer beseitigt. Auf der TechEd Europe im November 2007 stellten die Teilnehmer immer wieder die berechtigte Frage, warum Microsoft zwei verschiedene O/R-Mapper anbietet. Tatsächlich gibt Microsoft zu, dass die Ursache eine ungeplante Parallelentwicklung zweier verschiedener Entwicklungsteams bei Microsoft ist. Erst zu spät haben sich die Verantwortlichen bemüht, die beiden Konzepte zusammenzufassen. Die Empfehlung von Microsoft lautet, LINQ-to-SQL für einfache Mapping-Szenarien einzusetzen und das Entity Framework für komplexere Anwendungsfälle zu verwenden. Mapping-Szenarien Mapping-Szenarien ist das zentrale Stichwort, dass LINQ-to-SQL vom EF und den hier getesteten Drittanbietern unterscheidet. Mit einer Ausnahme beherrscht LINQ-to-SQL nur die Abbildung einer Tabelle auf genau eine Klasse, also alle Zeilen der Tabelle werden zu Instanzen dieser Klasse. Lediglich die zu verwendenden Spalten kann man hier einschränken. Die Ausnahme betrifft die Vererbung. LINQ-to-SQL kann alle Instanzen aller Klassen einer Vererbungshierarchie in einer einzigen Tabelle speichern. Nur mithilfe einer Unterscheidungsspalte (Diskriminator) kann LINQ-to-SQL auseinanderhalten, welche Zeile zu welcher Klasse gehört. Dieses Verfahren heißt in Fachkreisen Filtered Mapping, Shared Mapping, Flat Polymorphism oder Table per Hierarchy. Der wesentliche Nachteil des Verfahrens liegt auf der Hand: Diese eine Tabelle muss so breit sein wie die Menge aller Attribute aller Klassen in der Vererbungshierarchie, wodurch viele Zellen immer leer bleiben und somit Speicherplatz vergeuden. LINQto-SQL beherrscht weder andere Abbildungsmöglichkeiten für Vererbung noch die Auflösung der n:m-zwischentabellen oder die Abbildung einer Klasse auf mehrere Tabellen. Dabei können die Anforderungen an die Abbildung in der Praxis vielfältig sein. Abbildung 3 zeigt die Abbildungsmöglichkeiten, die es allein für den flachen Fall gibt. Neben der Abbildung einer Klasse auf eine Tabelle könnte der Entwickler sich wünschen, eine Klasse auf mehrere Tabellen oder eine Tabelle auf mehrere Klassen abzubilden. Der Grund ist, dass bei der Datenbank Gesichtspunkte wie Effizienz im Zugriff, Vermeidung von Redundanzen und Speicherplatz im Vordergrund stehen, während Objekte mehr eine natürliche, intuitive Sicht auf die Aufgabe und den Komfort des Softwareentwicklers ermöglichen und nahelegen. So lassen sich zum Beispiel die Spalten einer Tabelle in mehrere Unterobjekte (Composite Types) gruppieren. Auch ist es nicht absurd, in dem Objektmodell den aktuellen Flug eines Passagiers als Attribute in die Passagier-Klasse zu integrieren, während die Datenbank diesen Flug zusammen mit den weiteren vergangenen Flügen korrekt normalisiert in einer Detailtabelle pflegt. EF, Vanatec Open Access und Genome beherrschen hier alle Möglichkeiten. NDO kann nicht eine Klasse auf mehrere Tabellen abbilden. Das zweite wichtige Gebiet neben der Abbildung auf Entitätsebene ist die Abbildung von Beziehungen. Relationale Datenbanken verwenden Joins für 0/1:1 und 0/1:n-Beziehungen. n:m-beziehungen lassen sich nicht direkt abbilden. Objektmodelle hingegen verwenden Objektverweise. Eine 1:1-Beziehung ist hier ein Attribut des Typs der anderen Klasse. Mengenbeziehungen werden durch Objektmengen ausgedrückt, typisiert zum Beispiel als List oder untypisiert als ArrayList. Wenn die Klasse Flug eine Liste von Passagier-Objekten und die Klasse Passagier eine Liste von Flug-Objekten aufnehmen kann, dann existiert zwischen beiden eine m:n- Beziehung. Ein gutes ORM-Werkzeug sollte solche wechselseitigen Mengen und deren Abbildung auf die im relationalen Mo

4 dell notwendigen Zwischentabellen unterstützen (Abbildungen 4 und 5). Auch bei der Vererbung gibt es weitere Wünsche neben dem Filtered Mapping. Beim sogenanten Vertical Mapping alias Joined Mapping, alias Inheritance Table per Class, alias Vertical Polymorphism gibt es für jede Klasse in der Vererbungshierarchie genau eine Tabelle, also sowohl für die Unterklassen als auch die Basisklassen, selbst dann wenn diese abstrakt sind. Objekte entstehen hier also immer erst durch einen Join zwischen einer oder mehreren Tabellen. Dieses Verfahren verwendet keinen Speicherplatz, kostet aber Zeit durch die Joins. Beim Horizontal Mapping (alias Table per Subclass, alias Horizontal Polymorphism) gibt es Tabellen nur für konkrete Klassen. Diese Tabellen enthalten alle Attribute der Klasse als Spalten, auch die geerbten Attribute. Um alle Instanzen der Klasse X zu erhalten, ist nur eine Klasse abzufragen. Werden hingegen alle Instanzen der Oberklasse X und ihrer Unterklassen Y und Z benötigt, muss der Entwickler die Vereinigungsmenge der zugehörigen Tabelle X, Y und Z bilden. Dies ist jedoch akzeptabel, da dieser Fall seltener ist. Ein Blick in die Vergleichstabelle zeigt: EF, VOA, Genome und NHibernate unterstützen alle drei Vererbungsbildungen, während LINQ-to-SQL nur Filtered Mapping und NDO nur Horizontal Mapping bietet. Besonders hervorzuheben ist, dass das Entity Framework auch Abbildungsszenarien ohne ORM unterstützt. Dies ist möglich, indem man ein konzeptuelles Modell in EF definiert, aber nicht mit den ObjectServices arbeitet. Dann erfolgt der Zugriff auf die Daten über einen neuen ADO.NET-Datenprovider mit Namen EntityClient, also mithilfe von DataReader und DataSet. EntityClient erlaubt aber nur lesenden Zugriff. Die Abbildungsinformationen legen alle objektrelationalen Werkzeuge des Vergleichs in XML-Dateien ab. LINQ-to- SQL, NDO und NHibernate mit dem Zusatz NHibernate.Mapping.Attributes erlauben es auch, allein durch Annotationen im Quellcode die Abbildung zu steuern. Die XML-Dateien muss niemand von Hand schreiben, die ORM-Werkzeuge unterscheiden sich aber erheblich in Hinblick auf den Komfort. Abfragesprache Bevor es überhaupt etwas abzubilden gibt, muss der Softwareentwickler erst einmal festlegen, welche Daten er in den Speicher laden will. In relationalen Datenbanken geschieht dies mit SQL; und auch die ORM-Werkzeuge unterstützen SQL. Aber SQL ist nicht die erste Wahl für die Abfrage beim O/R-Mapping, denn SQL bezieht sich immer auf Tabellenstrukturen und ihre Tabellen und Spalten. Um jedoch ein Flug-Objekt zu laden, sollte auch dieser Name gültig sein und nicht der Namen der zugrundeliegenden Tabelle FL_Fluege. Die Object Query Language (OQL) der Object Data Manage- Bei Fachbüchern 50% und mehr sparen! dotnetpro 04/08 Neue MCITP / MCTS Training Kits Microsoft SQL Server 2005 Database Administrator Core Requirements Solid Quality Learning, J.C. Mackin, Mike Hotek, Orin Thomas, et al Schuber mit folgenden kompletten Examens- Vorbereitungen sowie interaktiven Praxistests auf CD: MCTS Exam : Microsoft SQL Server 2005 Implementation and Maintenance auch einzeln erhältlich unter Artikelnr. MS2271 statt EUR 60, nur EUR 29,95 MCITP Exam : Designing a Database Server Infrastructure Using Microsoft SQL Server 2005 auch einzeln erhältlich unter Artikelnr. MS2173 statt EUR 60, nur EUR 29,95 MCITP Exam Optimizing and Maintaining a Database Administration Solution Using Microsoft SQL Server 2005 auch einzeln erhältlich unter Artikelnr. MS2254 statt EUR 60, nur EUR 29,95 Microsoft Press englisch, ca Seiten Schuber, 3 Bände, Mediapack (DVD+CD) MS2377 statt 140,00 nur 89,95 Mehr zum SQL Server 2005 von Microsoft Press Introducing SQL Server 2005 for Developers MS1962 Programming Microsoft SQL Server 2005 MS1923 SQL Server 2005 Administrator s Companion MS2198 SQL Server 2005 Administrator s Pocket Consultant MS2107 statt 30,00 nur 10,00 statt 50,00 nur 24,95 statt 60,00 nur 29,95 statt 30,00 nur 14,95 Ihre erste Adresse für Remittenden Messerückläufer Sonderausgaben Ladenpreisaufhebung Jetzt schnell ins Internet auf dem Online-Bookshop in Kooperation mit

5 Tools Objektrelationale Mapper für.net im Vergleich ment Group (ODMG) ist eine Alternative zu SQL, die VOA und Genome einsetzen. OQL ist an dem Wort Extent zu erkennen, das allen Klassennamen nachzustellen ist, wenn die Menge der Instanzen der Klasse gemeint ist: SELECT * FROM FlugExtent AS Flug WHERE flug.flabflugort = 'Rom' NHibernate hat seine eigene objektorientierte Abfragesprache namens Hibernate Query Language (HQL). Ebenso NDO, doch hat der Hersteller ihr keinen eigenen Namen gegeben. Mit.NET 3.5 geht der Trend jedoch zur Language Integrated Query (LINQ), die Visual Studio 2008 elegant in die Sprachsyntax von C# und Visual Basic integriert. Aufgrund der dokumentierten Schnittstellen ist LINQ nicht alleine Microsoft vorbehalten und so gibt es schon zahlreiche LINQ-Provider von Drittanbietern, wie die Liste der Provider unter [3] belegt; darunter auch Vanatec und Genome. Bei Genomes Mapper hat LINQ schon OQL als primäre Sprache abgelöst, bestätigt dessen Hersteller TechTalk. In der aktuellen Genome-Version lassen sich einige Funktionen wie zum Beispiel Gruppierungen nur mit LINQ nutzen. Für NDO ist eine LINQ-Unterstützung in Planung. Bei NHibernate gibt es auch schon ein paar LINQ-Ansätze [5]. Das Entity SQL (esql) im ADO.NET Entity Framework ist vergleichbar mit HQL und OQL. Faul oder engagiert Die Definition der Abfrage selbst ist aber noch nicht alles, was über die tatsächlich zu ladenden Objekte entscheidet. Eine entscheidende Frage für die Leistungsfähigkeit von objektrelationalem Mappen ist die Frage, wann verbundene Objekte zu laden sind. Wenn der Entwickler zu einem Flug sofort alle Buchungen und die dazugehörigen Passagier- und Personendaten lädt, lädt er unter Umständen mehr als er wirklich braucht. Holt er die Daten jedoch nicht, muss er sie beim Zugriff auf eine Objektreferenz nachladen. Solch ein Nachladen bei Bedarf nennt sich Lazy Loading (alias Deferred Loading, alias Delayed Loading); das Gegenteil heißt übrigens Eager Loading (alias Immediate Loading). Lazy Loading ist der Standard in allen objektrelationalen Werkzeugen. Eager Loading lässt sich auf Ebene einer Datenbankverbindung (alias Datenkontext oder Data Scope) oder einer einzelnen Anfrage steuern. Lazy Loading ist eine besondere Herausforderung, denn das ORM-Werkzeug muss die Objektreferenzen quasi abfangen, um hier bei Bedarf Daten nachladen zu können. Dieses Abfangen erfolgt durch bestimmte Klassen für Einzelreferenzen und Mengenklassen. Der Unterschied zwischen den ORM-Werkzeugen liegt dabei darin, ob der Entwickler diese Klassen explizit im Code verwenden muss oder ob das ORM-Werkzeug diese beim Kompilieren oder zur Laufzeit austauscht. Microsoft verwendet sie folgendermaßen: für Einzelreferenzen EntityRef in LINQ-to-SQL und EntityReference in EF, für Mengen EntitySet in LINQ-to- SQL und EntityCollection in EF. Allen ORM-Werkzeugen ist gemein, dass die Mengenreferenzen nicht völlig beliebig sind, sondern dass sie nur ein bestimmtes Spektrum von Collection- Klassen unterstützen, die meist an bestimmten Schnittstellen festgemacht sind; Details nennt die Tabelle. Henne oder Ei Ein wesentliches Unterscheidungskriterium ist die Henne- oder Ei-Frage. Übertragen auf die Welt der O/R-Mapper geht es darum, ob der Entwickler zuerst die Datenbank erstellt und daraus dann Geschäftsobjekte generieren lässt oder erst die Geschäftsobjekte erstellt und daraus dann die Datenbank erzeugen lässt. Oder er macht beides manuell, erstellt also Geschäftsobjekte und Datenbank unabhängig voneinander und definiert dann eine mehr oder weniger komplexe Abbildung zwischen beiden Welten. Vielen Datenbankadministratoren sträuben sich sicherlich die Haare, wenn sie es einem Entwicklungswerkzeug überlassen sollen, Datenbanken zu erzeugen. Doch unter Java ist dies seit langem möglich und heißt Container Managed Persistance (CMP), wenn auch nicht ohne Kritik [6]. Dabei legt die Wortwahl der ORM- Werkzeuganbieter nahe, dass gerade dies der üblichere Weg ist. Wenn man erst Geschäftsobjekte erstellt und die Datenbank erzeugen lässt, sprechen sie von Forward Engineering. Den etwas negativ vorbelegten Begriff Reverse Engineering benutzen sie für Ansätze, in denen es die Datenbank zuerst gibt. Etwas neutraler werden die Begriffe, wenn man Mapping statt Engineering verwendet oder von Code First und Datenbase First spricht. Reverse Mapping unterstützen alle Anbieter. Beim Forward Mapping machen NHibernate und das ADO.NET Entity Framework bislang nicht mit; sie können eine Datenbank nicht auf Basis von Geschäftsobjekten generieren. Die anderen Anbieter unterscheiden sich dadurch, ob die Generierung der Datenbank zur Entwicklungszeit erfolgt (Vanatec, NDO, Genome) oder zur Laufzeit (LINQ-to-SQL). LINQ-to-SQL bietet hier einfach die Methode CreateDatabase() in dem Datenkontext an, den der Designer in Visual Studio generiert. LINQ-to-SQL kann allerdings Datenbanken nur anlegen oder löschen (DeleteDatabase()); Änderungen an bestehenden Datenbanken sind nicht möglich. Dies bedeutet also, dass alle Daten verloren gehen, wenn man nur ein Attribut in einem Geschäftsobjekt ergänzt genauer gesagt, dass man sich um die Datenmigration selbst kümmern muss. Schemaänderungen anwenden können bislang nur die Produkte VOA und NDO. Genome plant diese Funktion für die Version 3.5. Geschäftsobjektklassen Interessant ist, welche Anforderungen es an die Geschäftsobjektklasse gibt. Im Ideal fall ist jede beliebige einfache.net- Klasse auf eine Datenbanktabelle abzubilden, ohne dass die Klasse irgendeine Voraussetzung erfüllen muss. Die Fachwelt spricht dann von Persistance Ignorance oder von Plain Old CLR Objects (POCOs). In diese Kategorie fällt NHibernate. NDO kann POCOs als Unterobjekte eines zu persistierenden Objekts verwenden. Alle anderen Anbieter haben mehr oder weniger einschränkende Anforderungen: LINQ-to-SQL, EF, VOA und NDO erfordern eine Annotation durch ein.net-attribut. Eine bestimmte Basisklasse erfordert nur das EF. Genome zwingt den Entwickler, alle Geschäftsobjektklassen als abstrakte Klassen zu definieren. Die konkrete Implementierung liefert Genome dann in der generierten Assembly. Wenn die Geschäftsobjektklasse im Rahmen des Reverse Mapping entsteht, dann ist es wichtig zu sehen, welche Unterstützungen und Erweiterungsmöglichkeiten diese Klasse mitbringt. Eine gute

6 Unterstützung für Datenbindung in Windows-Forms-Anwendungen durch die Schnittstellen INotifyPropertyChanging und INotifyPropertyChanged bieten hier die Microsoft-Produkte. VOA enthält eine Klasse namens ObjectView, die die Rolle einer BindingSource bei der Datenbindung einnimmt. Eine komfortable Möglichkeit zur Datenbindung in ASP.NET-Webanwendungen bieten derzeit LINQ-to-SQL mit LinqDataSource (enthalten in ASP.NET 3.5), Genome mit der dort mitgelieferten GenomeDataSource und Vanatec mit dem ObjectView. Für alle anderen, einschließlich Microsofts EF, müssen die Entwickler derzeit selbst eine passende Manager- Klasse schreiben, um die seit ASP.NET 2.0 vorhandene ObjectDataSource zur Datenbindung zu nutzen. Auch Kleinigkeiten wie Benennungskonventionen können dem Entwickler das Leben schwer machen. Beim Reverse Mapping erzeugen alle Werkzeuge Geschäftsobjektklassen aus Tabellen, die so heißen wie die Tabellen in der Datenbank. Vanatec nimmt dabei allerdings Unterstriche aus dem Namen heraus. Bei der Bildung von Mengen von Geschäftsobjekten hängt LINQ-to-SQL immer ein kleines S an den Namen an. Das führt bei nicht-englischen Namen zu sehr unschönen Wörtern; dies lässt sich unter Tools/ Options/Database Tools/O/R Designer abschalten. Immerhin lassen sich in allen Werkzeugen die Namen der Geschäftsobjektklassen nachträglich ändern. Die größte Flexibilität bietet Genome, da sich die Benennung durch reguläre Ausdrücke steuern lässt. Mapping und Treiber Interessant ist, wie die Werkzeuge intern arbeiten. Nicht alle Werkzeuge verwenden im Untergrund ADO.NET. VOA und NHibernate arbeiten mit JDBC (Java Database Connectivity), da es sich um Portierungen aus der Java-Welt handelt. Wenn ADO.NET beim Lesen der Daten zum Einsatz kommt, dann natürlich kein DataSet mit seinem großen Overhead, sondern ein schlanker DataReader. Das Zurückschreiben von Änderungen erledigen alle ORM-Werkzeuge wie es sich aus Gründen der Leistung und Sicherheit gehört mit parametrisierten SQL-DML-Befehlen. Beim Speichern von Objekten unterstützen alle in der Vergleichstabelle genannten ORM-Werkzeuge Datenbanktransaktionen, auch in der Form über den in.net 2.0 eingeführten Namensraum System.Transactions. VOA, NHibernate und Genome erfordern bei jeder einzelnen Änderung eine explizite Transaktion. Das ist inhaltlich nicht schlimm, fordert aber die Fingerkuppen der Entwickler. Alle ORM-Werkzeuge unterstützen von der Datenbank automatisch vergebene Werte wie zum Beispiel automatisch hochzählende Primärschlüssel oder Zeitstempel; das heißt, nach dem Persistieren eines neu angelegten Objekts oder dem Ändern eines Objekts mit Zeitstempel fragen sie bei der Datenbank noch einmal Bei Fachbüchern 50% und mehr sparen! dotnetpro 04/08 SQL Server 2005 professionell Otey, Otey MI ,95 statt 45,00 nur noch 24,95 statt 60,00 nur noch 29,95 statt 39,95 nur noch 19,95 Inside SQL Server 2005 The Storage Engine Kalen Delaney (Solid Quality Learning) MS2105 Inside SQL Server 2005 T-SQL Programming Sarka, Wolter, Ben-Gan (Solid Quality Learning) MS2197 Inside SQL Server 2005 T-SQL Querying Sarka, Koller, Ben-Gan (Solid Quality Learning) MS2313 statt 45,00 nur noch SQL Server 2005 Database Essentials Step by Step Solid Quality Learning MS ,95 statt 40,00 nur noch 19,95 statt 40,00 nur noch 19,95 SQL Server 2005 Applied Techniques Step by Step Solid Quality Learning MS2316 SQL Server 2005 Analysis Services Step by Step Jacobson, Misner (Hitachi Consulting) MS2199 statt 40,00 nur noch SQL Server 2005 Reporting Services Step by Step Stacia Misner (Hitachi Consulting) MS2250 statt 45,00 nur noch 24,95 Ihre erste Adresse für Remittenden Messerückläufer Sonderausgaben Ladenpreisaufhebung Jetzt schnell ins Internet auf dem Online-Bookshop in Kooperation mit

7 Tools Objektrelationale Mapper für.net im Vergleich mit einem SELECT nach den aktuellen Werten. Für den gleichzeitigen Zugriff nutzen alle ORM-Werkzeuge das aus ADO.NET bekannte optimistische Sperren. Bis auf NDO unterstützen alle Werkzeuge sowohl die Konflikterkennung mit Originalwerten als auch Zeitstempel und Versionsnummer. NDO verfügt über einen eigenen GUID-basierten Mechanismus. Pessimistisch sperren kann der Entwickler bei allen Produkten über Transaktionen. Genome bietet darüber hinaus zum pessimistischen Sperren noch einen eigenen Anwendungsserver an. Um nun das eigentliche Mapping zwischen einem Datenbankzugriffsobjekt wie etwa dem DataReader und einem Geschäftsobjekt zur Laufzeit umzusetzen, braucht ein ORM-Werkzeug Programmcode, der die Geschäftsobjekte instanziert, die einzelnen Informationseinheiten aus der Datenbanktabelle entnimmt und in das Geschäftsobjekt überträgt. Grundsätzlich könnte dies per Reflection erfolgen, aber dieser Mechanismus wäre viel zu langsam. Microsoft und NHibernate nutzen daher Reflection in Kombination mit der Codegenerierung zur Laufzeit, das heißt, Programmcode in der Intermediate Language zur Abbildung zwischen Tabelle und Objekte wird zur Laufzeit erzeugt. VOA, NDO und Genome hingegen erzeugen den zusätzlichen Programmcode zur Entwicklungszeit durch weitere Kompilierungsschritte in Visual Studio. VOA und NDO reichern dabei die von Visual Studio erzeugten Assemblies mit entsprechenden IL-Befehlen an (Enhancing), während Genome eine weitere Assembly herstellt. Die Mehrheit der ORM-Werkzeuge bildet die Spalten auf einfache Attribute (Fields) ab. NHibernate und Genome stützen sich auf die Properties; nur NDO erlaubt beides. Unterstützung für die in.net 2.0 eingeführten wertelosen Typen unterstützen alle. Das heißt, dass die ORM-Werkzeuge im Gegensatz zu ADO.NET eine leere Integer-Zelle tatsächlich als int?, Integer? oder System.Nullable^Int32 und nicht als DBNull signalisieren. Da SQL und Datentypen datenbankspezifisch sind, benötigt ein ORM-Werkzeug für jedes Datenbankmanagementsystem einen speziellen Treiber. Derzeit bieten NHibernate und NDO hier die größte Vielfalt. Microsoft hat jedoch angekündigt, mit dem EF noch in diesem Jahr mehr Datenbanken unterstützen zu wollen als die Konkurrenz. Objektcontainer und Caching Nachdem ein Objekt in den Hauptspeicher geladen wurde, überwachen die ORM-Werkzeuge die Objekte auf Änderungen (Change Tracking), sodass beim Speichern nur die tatsächlich geänderten Objekte übertragen werden müssen. Für diese Änderungsverfolgung ist ein Container notwendig, in dem die Objekte im RAM leben. Diese Objektcontainer haben in allen Werkzeugen verschiedene, aber zum Teil ähnliche Namen: DataContext, ObjectContext, ObjectScope, Session, PersistanceManager und DataDomain. Ihnen gemeinsam ist, dass der Entwickler den Container vor der ersten Abfrage erzeugen und die Abfrage dann dort aufrufen muss, sodass die Container mitbekommen, welche Objekte mit welchem Ausgangszustand geladen werden. Die Objektcontainer öffnen die Datenbankverbindung meist selbst. Einige Werkzeuge erlauben auch, dass der Benutzer eine ADO.NET-Datenbankverbindung selbst erstellt und den Objektcontainer dann damit arbeiten lässt. Alle Objektcontainer speichern die geladenen Objekte in einem Cache und verhindern so, dass ein Objekt unnötig mehrfach geladen werden muss. Auch Inkonsistenzen verhindern die Container, wenn der Entwickler ein bereits im Arbeitsspeicher verändertes Objekt erneut durch eine andere Abfrage lädt. Alle Drittanbieter mieten darüber hinaus einen Zwischenspeicher auf zweiter Ebene (Second Level Cache), der containerübergreifend ist. NHibernate bietet hier mit der Auswahl zwischen der Zwischenspeicherung im Hauptspeicher, im ASP.NET-Cache, einer anderen Datenbank oder im Dateisystem die bei weitem größte Auswahl. Genome erlaubt genau wie NHibernate, selbst einen Second Level Cache zu schreiben. Sehr interessant ist das verteilte Zwischenspeichern in VOA: Verschiedene Anwendungsserver mit einem Zwischenspeicher können Änderungen in diesem über MSMQ-Nachrichten synchronisieren. Für NHibernate gibt es etwas Vergleichbares in Form des kommerziellen Produkts ncache. Serialisierung und Loslösung Wenn ein Geschäftsobjekt die Prozessgrenze verlassen muss, beispielsweise im Rahmen eines Webservices, dann ist seine Serialisierbarkeit wichtig. Die generierten Objekte mit der schon in.net 1.0 eingeführten Annotation [System.Serializable] zu versehen leisten nur die Designer für LINQ-to-SQL und NHibernate. Eine Auszeichnung für das in.net 3.0 eingeführte [System.Runtime.Serialization.DataContra ct] bieten LINQ-to-SQL und EF. [DataContract] verstehen nur WCF-Dienste. Bei allen anderen Werkzeugen ist das Fehlen von [Serializable] und [DataContract] kein Ausschlusskriterium; es bedeutet nur, dass der Entwickler diese Annotationen manuell hinterlegen muss. Viele Werkzeuge erstellen dazu die Geschäftsobjektklassen als partielle Klassen. Serialisierbarkeit ist aber nicht alles bei ORM: Die Änderungsverfolgung wird zu einem Problem, wenn die Geschäftsobjekte länger leben als der ORM-Container, zum Beispiel in Webanwendungen oder anderen zustandslosen Anwendungsservern. Hier spricht man von Mehrschichtunterstützung, Disconnected Objects oder Detached Objects. Bei allen hier untersuchten ORM-Werkzeugen ist es möglich, Geschäftsobjekte aus dem Container zu lösen, entweder durch einfaches Schließen des Containers oder eine explizite Operation. Große Unterschiede zeigen sich aber, wenn diese Objekte später wieder zu einem Container hinzugefügt werden sollen. Dies ist insbesondere dann notwendig, wenn der Entwickler Änderungen in den Objekten dauerhaft speichern will. Der neue Container muss aber wissen, ob es sich bei dem angefügten Objekt um ein geändertes, unverändertes oder neues Objekt handelt. Vanatec löst dies mit einem serialisierbaren Objektcontainer, der wie ein DataSet in ADO.NET die Prozessgrenzen überschreiten kann und die in ihm lebenden Objekte beobachtet. Die anderen Anbieter lösen dies über eine explizite Angabe beim Hinzufügen des Objekts, was aber dem Entwickler die Aufgabe überträgt zu wissen, welche der losgelösten Objekte sich tatsächlich verändert haben. Eine Besonderheit bietet Genome mit seinem Wire Object Protocol (WOP). Mit WOP lassen sich die Geschäftsobjekte in Datentransferobjekte in XML-Form serialisieren. Der Client verwendet eine durch WOP erzeugte Assembly mit Proxies für die Datentransferobjekte. Optional kann der Entwickler dabei sogenannte Tracked DTOs bekommen, die ein Dirty-Flag besitzen, das bei Änderungen gesetzt wird. Beim Rücktransfer zum Server lässt sich

8 so feststellen, was sich geändert hat. Mit Genome 3.5 soll WOP auch direkt die Servicekontrakte von WCF unterstützen. Plattformen und Werkzeuge Ein wesentlicher Unterschied zwischen den ORM-Werkzeugen sind die unterstützten Plattformen. VOA und Genome laufen ab.net 1.1, NHibernate sogar mit.net 1.0; NDO setzt.net 2.0 voraus. Die Microsoft-Produkte erfordern.net 3.5, das ADO.NET Entity Framework sogar noch die Erweiterungen, die erst Mitte 2008 erscheinen werden. Mono unterstützen nur NHibernate und NDO. Bisher ist übrigens keiner der hier verglichenen ORM-Werkzeuge für das.net Compact Framework verfügbar. Als erster Hersteller plant Vanatec einen Vorstoß ins mobile Framework noch im Laufe dieses Jahres. Innerhalb des Microsoft SQL Servers (SQLCLR) sieht bislang keiner der Anbieter einen Einsatzort für O/R-Mapper. Erhebliche Unterschiede gibt es auch bei der Werkzeugunterstützung. Microsoft bietet in Visual Studio 2008 Designer für LINQ-to-SQL (Abbildung 4) und das ADO.NET Entity Framework (Abbildung 5), wobei der Designer für EF zum Redaktionsschluss dieses Beitrags eine noch unfertige Erweiterung für Visual Studio 2008 war [7]. Designer bedeutet, dass der Entwickler aus den Datenbankverbindungen des Server-Explorers eine Tabelle, eine Sicht oder eine gespeicherte Prozedur auf eine Designeroberfläche fallen lassen kann und Visual Studio dann im Hintergrund Quellcode aufbaut..net-entwickler kennen dieses Verfahren schon von den typisierten DataSets, wobei der im Fall von LINQ-to-SQL und EF generierte Programmcode wesentlich schlanker und übersichtlicher ist. Leider bieten LINQ-to-SQL und das ADO.NET Entity Framework zwei verschiedene Designer mit unterschiedlichen XML-Formen und den Endungen dbml und edmx. Der EF-Designer (Abbildung 5) zeigt Kardinalitäten an den Beziehungslinien zwischen Entitäten an (0, 1, n), während der LINQ-to-SQL-Designer hier unterschied - liche Pfeil enden verwendet. Einen brauchbaren Designer bietet sonst nur noch NDO. Der für NHibernate verfügbare Designer [8] machte in mehreren Tests extrem viele Fehler in den Mapping-Dateien, die manuell auszubessern sind. Damit ist er praktisch unbrauchbar. Zudem gibt es den Designer bisher nur für Visual Studio Für NHibernate gibt es verschiedene andere Möglichkeiten zur Unterstützung bei der Erstellung der Mapping-Dateien, zum Beispiel SmartCode Studio, CodeSmith und MyGeneration [9]. Keines der vom Autor bisher begutachteten Werkzeuge ist aber so komfortabel wie ein Visual-Studio-Designer. Vanatec und Genome unterstützen den Entwickler nicht durch eigene Designer, sondern stellen ihm mehrere Assistenten sowie Dialogfenster zum Nachbearbeiten zur Seite. NDO und das Entity Bei Fachbüchern 50% und mehr sparen! Microsoft Windows Server 2003 Deployment Kit Microsoft Windows Server 2003 Resource Kit dotnetpro 04/08 Planning, Testing, and Piloting Deployment Projects Planning Server Deployments Designing and Deploying Directory and Security Services Designing a Managed Environment Deploying Network Services Deploying Internet Information Services (IIS) 6.0 Automating and Customizing Installations Windows Internals [4th Ed] Windows Registry Guide [2nd Ed] Windows Server 2003 Troubleshooting Guide Windows Server 2003 Performance Guide Windows Group Policy Guide Windows Administrator's Automation Toolkit Windows Security Resource Kit [2nd Ed] Microsoft Press englisch über Seiten plus ebooks und Tools Schuber mit 7 Bänden inkl. Media Kit MS1486 statt 200,00 nur 99,95 Microsoft Press englisch über Seiten plus ebooks und Tools Schuber mit 7 Bänden inkl. Media Kit MS2232 statt 250,00 nur 99,95 Ihre erste Adresse für Remittenden Messerückläufer Sonderausgaben Ladenpreisaufhebung Jetzt schnell ins Internet auf dem Online-Bookshop in Kooperation mit

9 Tools Objektrelationale Mapper für.net im Vergleich Vergleich wichtiger ORM-Werkzeuge für.net Produkt LINQ-to-SQL ADO.NET Entity Framework Vanatec OpenAccess (VOA) NHibernate Object Services Anbieter Microsoft, USA Microsoft, USA Vanatec GmbH, Deutschland Open Source Webadresse msdn2.microsoft.com/en-us/ msdn2.microsoft.com/en-us/ library/bb aspx library/aa697427(vs.80).aspx Preis kostenlos kostenlos 750, Express-Version kostenlos kostenlos Vorgängerprodukt ObjectSpaces ObjectSpaces Portierung von Java (JDO) Portierung von Java (Hibernate 2.1) Zeitpunkt der ersten Version November 2007 geplant drittes Quartal 2008 März 2005 Oktober 2005 Aktuelle Version Beta Anforderungen Unterstützte Datenbanksysteme MSSQL, MSSQL Compact MSSQL, MSSQL Compact; weitere angekündigt MSSQL, ADS (Sybase), Oracle, MySQL, SQL Anywhere, Firebird Erforderliche.NET-Version SP SP Unterstützung für Mono Weitere erforderliche Software J# Unterstützte.NET-Sprachen VB 9.0, C# 3.0 VB 9.0, C# 3.0 alle alle MSSQL, DB2, Ingres, Postgres, MySQL, Oracle, Sybase, Firebird, SQLLite Anwendungsgebiete Windows-Desktop-Anwendungen Webanwendungen Compact-Framework-Anwendungen SQLCLR-Code Tools Projektvorlagen für Visual Studio Elementvorlagen für Visual Studio LINQ-to-SQL-Klassen ADO.NET Entity Datenmodel Add-in für Visual Studio (2003/2005/2008) / // // // / Designer per Add-in Assistenten Entity Data Model Wizard Enable Project Wizard, Mapping Wizard, Data Form Wizard, Backend Configuration Wizard, Reverse Engineering Wizard Andere GUI-Tools esqlblast (Entity SQL Console) OQL Query Browser (Testabfragen, Anzeige des erzeugten SQLs) SmartCode Studio, CodeSmith, MyGeneration Kommandozeilentools SQLMetal.exe EdmGen.exe VEnhance, VSchema Hbm2ddl, Hbm2net, MapGenerator Dokumentation (CHM/PDF/HTML/HxS) / / // / // / // / / Mapping-Techniken Interne Datenzugriffs-API ADO.NET ADO.NET JDBC JDBC Basistechnik Reflection, Codegenerierung zur Laufzeit Reflection, Codegenerierung zur Laufzeit Enhancing bei der Kompilierung Forward Mapping Schemaänderungen anwenden Reverse Mapping Benennung der erzeugten Geschäftsobjektklassen Tabellenname Tabellenname Tabellenname ohne Unterstriche Tabellenname Reflection, Codegenerierung zur Laufzeit Benennung der erzeugten Geschäftsobjekt- Collections Geschäftsobjekte Direkte Abbildbarkeit einfacher.net-klassen (Persistance Ignorance/POCO) Tabellenname + s Tabellenname Tabellenname + s Tabellenname Erfordern spezifische Basisklasse Erfordern Annotation Erfordern parameterlosen Konstruktor Müssen abstrakt ein Erzeugte Geschäftsobjektklassen unterstützen INotifyPropertyChanging, INotifyPropertyChanging, INotifyPropertyChanged, ObjectView Datenbindung für Windows Forms INotifyPropertyChanged IListSource Erzeugte Geschäftsobjektklassen unterstützen Datenbindung für ASP.NET-Objektdatenquellen Erzeugte Geschäftsobjektklassen sind als [Serializable] gekennzeichnet Erzeugte Geschäftsobjektklassen unterstützen WCF-Kontrakte Erzeugt Geschäftsobjektklassen als partielle Klassen

10 .NET Data Objects (NDO) HoT - House of Tools Development GmbH, Deutschland Genome Tech Talk GmbH, Österreich für kommerzielle, kostenlos für Open-Source-Projekte 299 bis 1800 April 2005 November Abbildung 4 LINQto-SQL kann nur 1:1- Abbildungen zwischen Tabellen und Klassen verarbeiten. Daher erscheinen im Objektmodell künstliche Zwischentabellen. Sql Server, Access, Oracle, Firebird, MySql, Postgres, WebDB (LUW+AS/400) MSSQL, MSSQLCE, Oracle, DB (Genome 2x), 2.0 (Genome 3.x), 3.5 (Genome 3.x mit LINQ) alle VB, C# alle anderen ohne Visual- Studio-Integration / / / / Genome Web Application Project Wizard, ASP.NET CRUD Pages Wizard, Database Reverse Engineering Genome Query Analyzer ddsc (mapping schema compiler), wopc (data transfer object compiler), gas.exe (pessimistic locking server console) / / / / / / ADO.NET Enhancing bei der Kompilierung ADO.NET Erzeugung zusätzlicher Assemblies beim Kompilieren (MSBuild-Integration, eigener Projekttyp für VS) Tabellenname konfigurierbarer Tabellenname: Singularisation, unverändert, reguläre Ausdrücke Tabellenname konfigurierbarer Tabellenname: Singularisation, unverändert, reguläre Ausdrücke nur als Teil einer persistenten Klasse optional das Genome Wire Object Protocol lässt sich verwenden, um persistente Objekte in POCO Datentransfer-Objekte umzuwandeln Abbildung 5 Das ADO.NET Entity Frame - work stellt die Beziehung zwischen FL_Flug und PS_Passagier als echte m:n- Beziehung dar. Framework haben sowohl einen Designer als auch einen Assistenten zum Anlegen von Abbildungen. Visual Studio 2008 unterstützen alle außer NHibernate; Visual Studio 2005 wird von VOA, NHibernate, NDO und Genome unterstützt. Visual Studio 2003 ist nur zusammen mit VOA zu verwenden. Die Anbieter mit Designern bieten Elementvorlagen in Visual Studio, die sich zu einem beliebigen Projekt hinzufügen lassen. Vanatecs Tool speichert alle Mapping-Informationen in XML-Dateien mit der Erweiterung config, wobei diese Datei von dem Assistenten erzeugt wird, der nach dem Anlegen eines Projekts über den Menüpunkt Vanatec aufzurufen ist. Einzig Genome spendiert seiner Lösung eigene Projektvorlagen. Die Vorlage Web Application Project erzeugt die Grundstruktur für eine Genome-basierte Webanwendung. Ein Mapping Project ermöglicht, die Mapping-Informationen als ein eigenes Visual-Studio-Projekt zu führen und damit eine bessere Wiederverwendung, falls diese Daten in verschiedenen Projekten benötigt werden. Überwachung und Erweiterbarkeit Wie so oft bei der Bewertung von Software geht es auch hier um die Frage der Erweiterbarkeit, also die Möglichkeit, die Funktionen des Produkts zur erweitern und so bestehende Restriktion aufzuheben. Alle Anbieter ermöglichen es, über eigenen Programmcode den Lebenszyklus eines Geschäftsobjekts und des Objektcontainers zu überwachen und zu beeinflussen. Einige Anbieter sprechen hier von Interception, andere von Lifecycle Events oder Hooks. Interessant ist die Frage, ob sich andere Datenbankmanagementsysteme anbinden lassen. Dies erlauben NHibernate, NDO und das EF. Mit NHibernate kann der Entwickler seine Objekte nicht nur in relationalen Datenbanken, sondern theoretisch sogar auch in anderen Speichern,

11 Tools Objektrelationale Mapper für.net im Vergleich Vergleich wichtiger ORM-Werkzeuge für.net Produkt LINQ-to-SQL ADO.NET Entity Framework Vanatec OpenAccess (VOA) NHibernate Object Services Mapping-Arten Persistiert Felder/Eigenschaften //// Unterstützung für nullbasierte Werte 1 Klasse -> 1 Tabelle 1 Klasse -> n Tabellen n Klassen -> 1 Tabelle n Klassen -> m Tabellen Relationen 0/1:1 / 0/1:n / 0/n:m / // // // / Anforderungen für 0/1:1-Relationen EntityRef EntityReference Unterstützung für Collection-Typen EntitySet EntityCollection ArrayList, IList, ICollection, IDic. IList, ISet, IDictionary, ICollection Codebasiertes Mapping über Annotationen optional, mithilfe von Mapping- Attributen XML-basiertes Mapping / Mapping-Datei //// Mapping zur Kompilierungszeit (inklusive Fehlererkennung) Filtered- / Vertical- / Horizontal Mapping (bei Vererbung) / // // // / Tabellen-Mapping ohne Objekt-Mapping EntitityClient Zusammengesetzte Schlüssel Referenz über den Schlüssel (Objektreferenz kann aus Schlüsselattribut kontruiert werden) Abfragen Name des Containers DataContext ObjectContext ObjectScope Session Abfragesprachen LINQ, SQL esql, LINQ-to-Entitites OQL (OMG), LINQ, SQL HQL, SQL Parametrisierung der erzeugten SQL-Abfragen Von Nutzer definierte ADO.NET-Verbindungen eigener Verbindungs-Pool zum effizienteren Verwalten auf Grundla- ge von ADO.NET-Verbindungen Kompilierte Abfragen Lazy Loading Eager Loading Eager Loading Scope Kontext Abfrage Abfrage Abfrage Datenaktualisierung Speichern von geänderten Daten Änderungen bei einzelne Objekten verfolgen Änderungen bei Collections verfolgen Unterstützung von Autowerten/ID-Spalten Unterstützung von gespeicherten Prozeduren nur für SELECT Unterstützung von gespeicherten Prozeduren mit multiplen Ergebnis-Sets Unterstützung für Table-Valued Functions AutoInc Unterstützung von Transaktionen Integration mit System.Transactions Transaktionen erforderlich für alle Schreib - operationen Pessimistisches Sperren (bei Transaktionen) Optimistisches Sperren Konfikterkennung mit Originalwert/Zeitstempel/ / // // // / Versionsnummer Lazy Loading skalarer Eigenschaften einer Objektinstanz Multi-Tier-Unterstützung bei losen Objekten Änderungen bei unverbundenen Objekten verfolgen EntityBag (Add-on) ObjectContainer Cache First Level Cache (Session Level) Second Level Cache (Arbeitsspeicher/ASP.NET/ / / // / // / // / / Datenbank/Dateisystem) Verteiltes Caching MSMQ NCache (kommerzielle Version) Eigener Second Level Cache implementierbar auf Anfrage beim Hersteller Monitoring Logging/Tracing TraceSources log4net Windows-Leistungsindikatoren Erweiterbarkeit Überwachen von Objekten mit eigenen Codes Eigene Datenbank-Provider Sonstige Erweiterungen andere Persistenzmechanismen, SQL-Dialekt, SQL-Sprachersetzung, ID-Generator, etc

12 .NET Data Objects (NDO) Genome / / / (Version 2.0) / / / / IList IEnumerable<T>, ICollection<T> optional, erzeugt eine Mapping-Datei / / / / / / PersistenceManager DataDomain eigene SQL-ähnliche Abfragesprache, SQL LINQ, OQL, SQL Abfrage Abfrage teilweise automatisch aus LINQ- oder OQL- Ausdrücken generierbar /eigener GUID-basierter / / Mechanismus/ / / / / / / etwa in einer Datei oder einem LDAP- Server, die Zeit überdauern lassen. Bei LINQ-to-SQL will Microsoft nicht, dass andere Datenbanken außer dem hauseigenen SQL Server inklusive seiner Express-Version und SQL Server Compact angesteuert werden können. No public provider model is available. At this time, LINQ to SQL supports SQL Server and SQL Server Compact 3.5 only. heißt es im LINQ-to-SQL FAQ [10]. Beim ADO.NET Entity Framework will Microsoft Drittanbieter bei der Erstellung eigener Provider unterstützen. Noch im Lauf des Jahres sollen zahlreiche Provider erscheinen, sowohl von Datenbankherstellern als auch Firmen wie OpenLink Software und DataDirect Technologies, die bisher schon als unabhängige Lieferanten für Datenbanktreiber aufgetreten sind. Wenn Microsoft Wort hält, wird das EF das ORM-Werkzeug mit der breitesten Datenbankunterstüzung werden. Die größte Flexibilität bei der Erweiterbarkeit bietet insgesamt eindeutig NHibernate, nicht nur weil es ein Open- Source-Projekt ist, sondern auch weil hier sehr viele Bausteine auf Austauschbarkeit hin angelegt sind. NHibernate bietet aber neben eigenen Datenbank-Providern auch andere Erweiterungsmöglichkeiten, zum Beispiel die Einflussnahme auf die Vergabe von automatischen Primärschlüsseln oder die Codeerzeugung zur Laufzeit. Genome und NHibernate erlauben die Implementierung eigener Second Level Caches. Im Bereich der Überwachung bieten alle Produkte neben den Lebenszyklusereignissen auch einfachere Möglichkeiten, die Arbeit des ORM- Werkzeugs zu protokollieren, etwa um die erzeugten SQL-Befehle auf der Konsole oder in eine Datei auszugeben. Eine Überwachung durch die Windows-Leistungsindikatoren bietet nur VOA. Fazit Am Ende dieses Vergleichs fällt es sehr schwer, einen eindeutigen Gewinner auszumachen. Hinsichtlich der Mapping- Möglichkeiten etwas abgehängt ist eindeutig LINQ-to-SQL. Mehr Flexibilität gibt es im EF, die Microsoft aber mit einem Verzicht auf das Forward Mapping erkauft; bis zum Erscheinen dauert es jedoch noch einige Monate, in denen es noch Änderungen an den Funktionen geben kann. Außerdem kann im EF die Anforderung, dass die Geschäftsobjektklasse eine bestimmte Basisklasse besitzen muss, bei der freien Entfaltung des Objektmodells sehr stören. Noch unterstützen weder LINQ-to-SQL noch EF andere Datenbanken als SQL Server. Immerhin hat Microsoft hier Großes angekündigt. Bei den Drittanbietern fällt das Open-Source-Projekt NHibernate trotz der breiten Unterstützung unterschiedlicher Datenbanken hinter die kommerzielle Konkurrenz zurück, weil es kaum grafische Werkzeuge bietet. Zwischen den drei Drittanbietern eine Bewertung abzugeben wäre nicht fair, denn der Autor kennt nur VOA aus der Praxis. Das ADO.NET Entity Framework dürfte langfristig die größte Überlebenswahrscheinlichkeit haben. LINQ-to-SQL wird Microsoft wieder auf das Abstellgleis schieben; und die Drittanbieter werden es sehr schwer haben, ihre Werkzeuge noch zu verkaufen, wenn Microsoft die meisten Fälle schon abdeckt. Eine Marktbereinigung findet hier auf jeden Fall statt, wobei die hier verglichenen Dritt anbieter im Markt noch recht gut aufgestellt sind im Vergleich zu den vielen kleineren Anbietern. [1] ADO.NET Entity Framework & LINQ to Relational Data, f dnplink SL0408ORM1 [2] NHibernate Resources, f dnplink SL0408ORM2 [3] Erläuterung von LINQ einschließlich einer Liste von LINQ-Providern, f dnplink SL0408ORM3 [4] Holger Schwichtenberg: Das ADO.NET Entity Framework, dotnetpro 5/2007, Seite 94 ff. [5] Implementing Linq for NHibernate: A How To Guide, f dnplink SL0408ORM4 [6] For JDO, the Time is Now, f dnplink SL0408ORM5 [7] ADO.NET Entity Framework Tools Dezember CTP, f dnplink SL0408ORM6 [8] NHibernate Add-in für Visual Studio 2005, f dnplink SL0408ORM7 [9] Perseus: Entity Framework EntityBag, f dnplink SL0408ORM8 [10] Frequently Asked Questions (LINQ to SQL), f dnplink SL0408ORM9 Callbacks, eigene NDO-Provider, eigene Caching-Provider Persistenz-Handler Bitte beachten Sie folgenden wichtigen Hinweis zum Ursprung der Daten in der Tabelle: Die Angaben zu LINQ-to-SQL, ADO.NET Entity Framework und NHibernate wurden vom Autor des Beitrags erhoben. Die Angaben zu Vanatec Open Access, NDO und Genome wurden von den Herstellern geliefert. Der Autor hat nur die Angaben von Vanatec Open Access zum Teil an eigenen Projekten verifiziert. Der Autor hat NDO und Genome nicht selbst im Projekteinsatz und kann die Angaben der Hersteller hier nicht überprüfen