O/R-Mapping in .NET Das ADO.NET Entity Framework

Fachhochschul-Bachelorstudiengang
SOFTWARE ENGINEERING
A-4232 Hagenberg, Austria
O/R-Mapping in .NET
Das ADO.NET Entity Framework
Bachelorarbeit
Teil 1
zur Erlangung des akademischen Grades
Bachelor of Science in Engineering
Eingereicht von
Günter Zöchbauer
Begutachter: Dipl.-Ing. Johann Heinzelreiter
Hagenberg, Dezember 2008

© Copyright 2008 Günter Zöchbauer
http://www.entityframework.de
Alle Rechte vorbehalten

Inhaltsverzeichnis
Kurzfassung iv
Abstract v
1 Einleitung und Motivation 1
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 4
2.1 O/R-Mapping-Framework . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Wozu objektrelationale Abbildung? . . . . . . . . . . . 4
2.1.2 Data Mapper . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Metadaten-Abbildung bzw. O/R-Mapping-Framework 5
2.2 Abbildungsszenarien . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Objektidentität . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Eingebetteter Wert (Embedded Value) . . . . . . . . . 9
2.2.4 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 Arbeitseinheit (Unit of Work) . . . . . . . . . . . . . . 12
2.2.6 Nebenläufigkeit (Concurrency) . . . . . . . . . . . . . 13
2.2.7 Laden bei Bedarf (Lazy Loading) . . . . . . . . . . . . 13
2.2.8 Unabhängigkeit der Entitätsklassen von der Persistenzschicht
(Persistence Ignorance) . . . . . . . . . . . 14
2.2.9 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.10 Weitere Aufgaben einer O/R-Mapping-Lösung . . . . 15
3 Evaluierung 17
3.1 Verglichene Produkte . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 ADO.NET Entity Framework . . . . . . . . . . . . . . 17
3.1.2 Genome . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.3 NHibernate . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1 Metadaten . . . . . . . . . . . . . . . . . . . . . . . . 21
ii

Inhaltsverzeichnis iii
3.2.2 Objektidentität . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Eingebetteter Wert . . . . . . . . . . . . . . . . . . . . 30
3.2.5 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.6 Nebenläufigkeit . . . . . . . . . . . . . . . . . . . . . . 30
3.2.7 Abfragen . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Unabhängigkeit der Entitätsklassen von der Persistenzschicht
(Persistence Ignorance) . . . . . . . . . . . 32
3.3.2 Unterstützte Datenbanksysteme . . . . . . . . . . . . 34
3.4 Produktivität . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1 Codegenerierung . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Designer-Werkzeug . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Visual Studio Integration . . . . . . . . . . . . . . . . 38
4 Implementierung 39
4.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1 Visual Studio Projektorganisation . . . . . . . . . . . 40
4.2.2 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 ID-Generierung . . . . . . . . . . . . . . . . . . . . . . 42
4.2.4 Beziehungen . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.5 Feingranulares Objektmodell . . . . . . . . . . . . . . 44
4.2.6 Nebenläufigkeit . . . . . . . . . . . . . . . . . . . . . . 44
5 Resumee und Ausblick 46
5.1 Resumee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Literaturverzeichnis 49

Kurzfassung
Objektrelationale Abbildung (O/R-Mapping) ist das Überwinden der konzeptionellen
und technischen Unterschiede zwischen dem Objektmodell in
objektorientierten Programmiersprachen und dem relationalem Modell in
Datenbankmanagementsystemen (RDBMS). So wird beispielsweise das Konzept
der Vererbung im relationalen Modell nicht unterstützt. Auch die Identität
von Entitäten sowie die Beziehungen zwischen Entitäten wird in diesen
Modellen unterschiedlich dargestellt. Das Überwinden dieser Unterschiede
stellt eine erhebliche Herausforderung für Softwareentwickler dar.
Für die Microsoft-.NET-Plattform wird eine Reihe fertiger Produkte angeboten,
die diese Abbildung übernehmen. Seit der Version 3.5 Service Pack
1 ist das O/R-Mapping-Framework ADO.NET Entity Framework integraler
Bestandteil der Microsoft .NET-Plattform.
Diese Arbeit untersucht, ob das ADO.NET Entity Framework bereits
für den produktiven Einsatz geeignet ist und vergleicht den Funktionsumfang
mit etablierten Produkten. Für diesen Vergleich wurde das kommerzielle
O/R-Mapping-Framework Genome von TechTalk sowie das quelloffene
NHibernate herangezogen. Im Rahmen dieser Arbeit werden die grundlegende
Anforderungen an ein O/R-Mapping-Framework, die Visual Studio-
Integration, der Beitrag zu höherer Produktivität sowie der Einfluss auf die
Softwarearchitektur untersucht.
Mit einer Beispielapplikation wird veranschaulicht, welche objektorientierten
Konstrukte auf das relationale Modell abbildbar sind und welche
Einschränkungen gegebenenfalls bei den untersuchten Produkten zu berücksichtigen
sind.
iv

Abstract
Object-relational-mapping (O/R-mapping) is a technique to overcome the
complexities when mapping objects of object oriented languages to the relational
model of database management systems (RDBMS). For example,
inheritance is not supported in the relational model. Even the identity of
entities or the relations between entities are represented differently. A considerable
effort is necessary by software engineers to overcome this mismatch.
Several solutions are available for the Microsoft-.NET plattform which
provide this functionality. With the release of .NET 3.5 Service Pack 1, the
O/R mapping framework ADO.NET Entity Framework became an integral
part of the Microsoft .NET plattform.
This thesis verifies if the ADO.NET Entity Framework is applicable for a
productive environment and compares its features with establied solutions.
The commericial O/R-mapping framework Genome by TechTalk and the
open source solution NHibernate are consulted for this comparsion.
This paper examines and compares the basic features usually provided
by O/R mapping frameworks, the integration into Visual Studio as well as
the benefit for productivity and its influence in software architectures.
A sample application demonstrates object-relational constructs and how
they are mappable via the O/R mapping frameworks. A special focus is set
on the restrictions given by the examined technologies.
v

Kapitel 1
Einleitung und Motivation
1.1 Aufgabenstellung
Diese Arbeit vergleicht ADO.NET Entity Framework [26, 27], Microsofts
neue O/R-Mapping-Technologie, mit zwei etablierten Produkten, NHibernate
[40] sowie TechTalk Genome [59].
Untersucht und gegenübergestellt werden die grundlegende Anforderungen
an ein Persitenzframework, die Visual Studio-Integration, der Beitrag
zu höherer Produktivität sowie Auswirkungen auf die Softwarearchitektur
(z. B. in Bezug auf „Separation of concerns“). Des Weiteren wird untersucht,
inwieweit die aktuelle Version des Microsoft ADO.NET Entity Framework
bereits für den produktiven Einsatz geeignet ist.
1.2 Motivation
Ein Großteil moderner Geschäftsapplikationen wird mittlerweile in objektorientierten
Programmiersprachen wie Java und C# erstellt und die Objekte
üblicherweise in einer relationalen Datenbank persistiert. Zwischen Objektmodell
und relationalem Modell der Datenbank gibt es einige technische und
konzeptionelle Unterschiede. Das Überwinden dieser Unterschiede stellt eine
erhebliche Herausforderung für Softwareentwickler dar. Schon in den frühen
90er-Jahren wurden z. B. für Smalltalk Standardlösungen angeboten 1 , die
dem Entwickler diese Aufgabe abnehmen oder zumindest erleichtern sollten.
Die Popularität der Java-Plattform hat in diesem Bereich die Entwicklung
vorangetrieben. Für Java gibt es seit einigen Jahren leistungsfähig O/R-
Mapping-Lösungen, die großteils quelloffen sind und eine weite Verbreitung
gefunden haben. Mit JPA 2 hat Sun eine einheitliche API für die Nutzung
1 z. B. Enterprise Objects Framework, das in Apples WebObjects [2] aufging oder Top-
Link [37, 52], das von Oracle in einer Java-Version angeboten wird.
2 Java Persistance API [55]
1

1. Einleitung und Motivation 2
verschiedener Persistenzframeworks in Java integriert.
Im .NET-Umfeld besteht diesbezüglich noch Aufholbedarf. Es werden
einige leistungsfähige O/R-Mapping-Lösungen für .NET angeboten, doch
Microsofts Ankündigung ein eigenes Produkt anzubieten, verunsicherte Anwender
wie Mitbewerber. Verschärft wurde diese Situation dadurch, dass
Microsoft das im Jahr 2001 erstmals angekündigte Produkt ObjectSpaces
[8], [Esp04] aufgegeben hat um im Jahr 2005 dafür die neue Technologie
LINQ 3 sowie Entity Framework anzukündigen [1, 5, 31].
Eine O/R-Mapping-Lösung für ein Projekt einzusetzen, hat weitreichende
Auswirkungen auf die Softwarearchitektur. Die angebotenen Lösungen
verfolgen teilweise unterschiedliche Ansätze mit unterschiedlichen APIs, wodurch
es schwierig und kostspielig werden kann, die Entscheidung für ein
konkretes Produkt später zu revidieren.
Laut aktuellem Informationsstand wird Microsoft ADO.NET Entity Framework
als Teil des .NET-Frameworks ausgeliefert werden, somit kostenlos
Verfügbar sein und nicht zuletzt deshalb eine interessante Option für viele
Entwickler darstellen. Diese Lösung wird daher schon vor der endgültigen
Fertigstellung untersucht, um frühzeitig eine Entscheidungsgrundlage verfügbar
zu haben.
1.3 Zielsetzung
Die Arbeit zeigt, inwieweit das Microsoft ADO.NET Entity Framework in
der vorliegenden Version 4 ein ausgereiftes Produkt darstellt, das für den Einsatz
in komplexeren Projekten geeignet ist. Es untersucht, ob ADO.NET
Entity Framework bereits den Funktionsumfang etablierter Produkte anderer
Hersteller bietet bzw. in welchen Bereichen es diesen überlegen ist.
Unterschiedliche Lösungsansätze werden gegenübergestellt, ohne diese notwendigerweise
zu bewerten.
Dutzende kommerzielle und frei verfügbare Persistenzframeworks werden
für Microsoft .NET angeboten. Da alle diese Produkte in den Vergleich
einzubeziehen, den Rahmen dieser Arbeit bei Weitem überschreiten würde,
wurde die Auswahl auf zwei Produkte eingeschränkt, die mit dem ADO.NET
Entity Framework verglichen werden. Aus den verfügbaren quellofenen Lösungen
wurde NHibernate, aus den kommerziellen Angeboten TechTalk Genome
für den Vergleich ausgewählt. Alle drei Produkte verfolgen einen ähnlichen
Lösungsansatz, Abbildung per Metadaten, wobei NHibernate und
Entity Framework für Objekterzeugung und Zugriff auf die Entity-Objekte
hauptsächlich auf Reflection setzen, Genome hingegen zur Übersetzungszeit
den Quelltext für die Abbildung generieren.
3 Language INtegrated Query
4 Microsoft Visual Studio 2008 Service Pack 1 und .NET Framework 3.5 Service Pack
1 [26, 28]

1. Einleitung und Motivation 3
Neben den grundlegenden Funktionalitäten eines O/R-Mapping-Frameworks
wird untersucht, welche Unterstützung dem Softwareentwickler bei
der Arbeit mit dem Framework geboten wird bzw. wie komfortabel der Entwickler
damit arbeiten kann (z. B. welche Assistenten und grafische Werkzeuge
für die Erstellung der Abbildungs-Metadaten und Enitätsklassen bereit
gestellt werden), wie die Integration in Visual Studio realisiert wurde
und wie weit es notwendig ist, die Softwarearchitektur einer Anwendung auf
das eingesetzte Persistenzframework abzustimmen.
Die einzelnen Aspekte werden herausgearbeitet, indem eine Beispielanwendung
realisiert wird, anhand derer die Umsetzung bestimmter Funktionalität
mit den einzelnen Testkandidaten untersucht und dargestellt wird.
Nicht näher eingegangen wird auf die von den Produkten angebotenen
Abfragesprachen, Caching, Abbildung von Stored Procedures oder zusammengesetzte
Primärschlüssel. Weitgehend unberücksichtigt bleiben Datenbindung
sowie generell die Anbindung an die Benutzeroberfläche oder andere
Clients. Ein weiterer Aspekt der hier nicht untersucht wird, ist die
Unterstützung von 3-Tier-Architektur, bei der persistente oder transiente
Objekte bzw. Objektgraphen serialisiert über Prozess- und Rechnergrenzen
hinweg übertragen werden.
Außerdem wird davon ausgegangen, dass Microsoft Visual Studio 2008
mit der .NET-Implementierung von Microsoft verwendet wird. Alternative
.NET-Implementierungen (z. B. Mono [33]) oder IDEs (z. B. SharpDevelop
[9]) bleiben unberücksichtigt.

Kapitel 2
Grundlagen
Die theoretischen Grundlagen für die Persistierung von Objekten in relationalen
Datenbankmanagementsystemen (RDBMS) werden in der Literatur
ausgiebig diskutiert (z. B. [Fus97,Amb06a,FRF02,Nil06]). Dieser Abschnitt
stützt sich weitgehende auf die Ausführungen in [FRF02] und fasst die für
die weitere Diskussion relevanten Themen zusammen.
2.1 O/R-Mapping-Framework
O/R-Mapping-Lösungen sind, nicht zuletzt seit Microsofts Ankündigung
ein entsprechendes Produkt liefern zu wollen, ein viel diskutiertes Thema.
Warum es sinnvoll sein kann, einen O/R-Mapping-Framework einzusetzen,
welche Aufgaben er erfüllen kann und welche Problematiken dabei auftreten,
wird nachfolgend analysiert.
2.1.1 Wozu objektrelationale Abbildung?
Vor einigen Jahren war es noch üblich, Geschäftslogik in der Datenbank
(z. B. Oracle PL-SQL) oder in anderen prozeduralen Sprachen wie C, Pascal
oder VisualBasic zu implementieren und ist auch noch heute in vielen
Projekten gängige Praxis. Diese Vorgangsweise entspricht dabei meist dem
unter [FRF02, S. 111] beschriebenen „Transaction Script“.
“Organizes business logic by procedures where each procedure
handles a single request from the presentation.”
Die Einfachheit ist der große Vorteil dieses Ansatzes und hat daher nach
wie vor seine Berechtigung. Bei einfacher Geschäftslogik ist es naheliegend,
diesen Lösungsansatz zu wählen, da er leicht zu verstehen ist und der geringe
Overhead sich positiv auf die Geschwindigkeit auswirkt.
Steigende Komplexität der Geschäftslogik macht es zunehmend schwieriger,
eine übersichtliche Struktur beizubehalten. Jedes Transaktionsskript
4

2. Grundlagen 5
ist darauf ausgelegt, genau eine Transaktion abzubilden. Dabei ist darauf
zu achten, dass allgemeiner Code nicht mehrfach implementiert wird. Die
Vorzüge der objektorientierten Programmierung (OOP), Komplexität durch
Kapselung der Daten und Kombination mit zugehöriger Programmlogik in
Objekten sowie differenziertere Abbildung von Beziehungen mithilfe der Vererbung
handhabbar zu machen, bleiben ungenutzt. Der in [FRF02, 116] als
„Domain Model“ beschriebene Ansatz (vgl. auch DDD (Domain-Driven Design)
[Eva03, Nil06]) rückt gerade diese Möglichkeiten in den Vordergrund.
Bei einem Domänenmodell kann zwischen einfachem und komplexem
Domänenmodell unterschieden werden, wobei das einfache Domänenmodell
weit gehend mit dem Datenbankschema übereinstimmt, das komplexe dagegen
beträchtlich davon abweichen kann. Entsprechend aufwändig ist es,
ein komplexes Domänenmodell in ein RDBMS zu persistieren, bzw. einen
Objektgraphen daraus wiederherzustellen. Für das einfache Domänenmodell
kann z. B. „Active Record“ [FRF02, S. 160] verwendet werden, für das
komplexe ist dagegen ein „Data Mapper“ [FRF02, S. 165] erforderlich.
2.1.2 Data Mapper
Ein Data Mapper ist eine Vermittlungsschicht, die Daten zwischen Objekten
im Speicher und Datenbank transferiert und dabei die technischen und
konzeptionellen Unterschiede zwischen Objektmodell und relationalem Modell
[Cod90], in der Literatur teilweise als „Object relationinal impedance
mismatch“ [Amb06b] oder nur „Impedance Mismatch“ bezeichnet, überwindet.
Objekte und Datenbank sollen möglichst unabhängig voneinander
bleiben und die Objekte keine Kenntnis über die Existenz der Datenbank,
in die sie persistiert werden, benötigen (siehe Unterabschnitt 2.2.8).
Vollständige Unabhängigkeit von der Persistenzschicht wird zwar angestrebt,
ist aber kaum ohne schwerwiegende Nachteile, vor allem bzgl. Laufzeitoverhead,
realisierbar [Nil06, S. 182]. Daher werden meist gewisse Kompromisse
eingegangen.
Die Trennung zwischen Domänen- und relationalem Modell stellt sicher,
dass beide Modelle unabhängig weiterentwickelt werden können und hat zusätzliche
Vorteile wie z. B. die Möglichkeit, das Domänenmodell unabhängig
von der Datenbank zu testen oder durch Austausch des Abbildungsframeworks
in ein anderes RDBMS zu persistieren.
2.1.3 Metadaten-Abbildung bzw. O/R-Mapping-Framework
Eine spezielle Ausprägung des Data Mapper-Entwurfsmusters ist „Metadata
Mapping“ [FRF02, S. 306], die allgemein als O/R-Mapping-Framework
bezeichnet wird (vgl. [Nil06, S. 289]).
Für das Abbilden wird entweder ein universelles Data Mapper Framework
per Metadaten konfiguriert oder aus den Metadaten zur Kompilierzeit

2. Grundlagen 6
Code für die konfigurierte Abbildung generiert. Mischformen sind möglich
und auch üblich.
Per Metadaten wird definiert, wie bestimmte Objekte und Objektgraphen
in das relationale Modell transformiert bzw. wie aus diesen persistierten
Daten Objekte rekonstruiert werden sollen. Die Metadaten liegen
üblicherweise als XML-Datei vor oder sind als Attribute in die Klassendefinitionen
eingebettet.
Eine O/R-Mapping-Lösung abstrahiert das eingesetzte RDBMS weitgehend
und bietet eine Schnittstelle mit Methoden, um z. B. neue Objekte
für die Persistierung zu registrieren oder Abfragen auszuführen und die entsprechenden
Objekte zurückzuliefern. Die Kommunikation mit dem RDBMS
sowie die Umsetzung der Methodenaufrufe in SQL-DML 1 -Statements erfolgt
transparent. Durch das Zusammenfassen des Datenbankzugriffes in einer eigenen
Schicht (Layer [FRF02, S. 17]), wird die Komplexität der Applikation
reduziert.
Im Detail führt das zu einer Reihe von Aufgaben, die zu lösen sind. Nicht
jeder O/R-Mapping-Lösung unterstützt alle möglichen Szenarien. [Fus97]
unterscheidet z. B. fünf Ausbaustufen.
Einfache O/R-Mapping-Lösungen bilden nur Objekte ab, deren Strukturen
dem Datenbankschema direkt entsprechen (einfaches Domänenmodell).
Leistungsfähigere O/R-Mapping-Lösungen können auch Objektmodelle persistieren,
die weitere Ausdrucksmöglichkeiten der OOP nutzen, für die keine
direkte Entsprechung im relationalen Modell existiert, z. B. Vererbung (komplexes
Domänenmodell).
Für eine Geschäftstransaktion wird ein Teil der Daten aus der Datenbank
angefordert und als Objekte rekonstruiert. Diese Objekte werden während
der Transaktion geändert, gelöscht bzw. neue Objekte erstellt. Das Zusammenführen
dieser Änderungen mit dem Datenbestand im RDBMS am Ende
der Transaktion gehört zu den Aufgaben des O/R-Mapping-Frameworks.
Dabei darf der bei RDBMS übliche gleichzeitige Zugriff mehrerer Clients
nicht zu inkonsistenten Daten führen.
Üblicherweise wird ein O/R-Mapping-Framework mit einem Satz von
Werkzeugen wie grafische Designer und Assistenten geliefert, die dem Entwickler
das Entwerfen der Entitätsklassen und der Konfiguration der Abbildung
erleichtern. Je nach Lösungsansatz wird automatisch Code für Entitätsklassen
und das Abbilden generiert.
Optimierungen sind notwendig, damit der gewonnene Komfort möglichst
nicht durch Einbußen bei der Geschwindigkeit erkauft wird.
1 Data Manipulation Language

2. Grundlagen 7
2.2 Abbildungsszenarien
Eine O/R-Mapping-Lösung benötigt Strategien für verschiedenste Konstrukte
und Szenarien, auf die nachfolgend näher eingegangen wird.
Je nach Konfiguration und Unterstützung durch das verwendete O/R-
Mapping-Framework werden Properties oder private oder öffentliche Datenkomponenten
persistiert. In weiterer Folge wird in diesem Zusammenhang
nur der Begriff Properties verwendet.
2.2.1 Objektidentität
Entitäten (vgl. Entities [Eva03, S. 89] und [Nil06, S. 462]) im Arbeitsspeicher
müssen den zugehörigen Datensätzen in der Datenbank eindeutig zuordenbar
sein. Die Identität von Objekten ist anders definiert (z. B. über
die Adresse im Arbeitsspeicher) als die von Datensätzen in einem RDBMS,
die über den Primärschlüssel, ein oder mehrere Attribute des Datensatzes,
identifiziert werden.
Der Primärschlüssel (Primary key, PK) kann auf unterschiedlich Weise
gebildet werden, z. B. als natürlicher Schlüssel (Meaningful key, Natural
key), wobei bestehende Attribute als Primärschlüssel verwendet werden.
Eine bessere Alternative, vor allem für den Einsatz mit O/R-Mapping-
Lösungen, sind künstliche Schlüssel (Meaningless key, Surrogate key, Surrogat).
Dabei wird eine zusätzliches Attribut eingefügt, dessen Bedeutung
ausschließlich darin besteht, den Datensatz eindeutig zu identifizieren. Werden
natürliche Schlüssel verwendet, führt das, z. B. bei m:n-Beziehungen, zu
kombinierten Schlüsseln, bei denen mehrere Attribute den Primärschlüssel
bilden. Kombinierte Schlüssel verkomplizieren das Abbilden.
Die Werte für künstliche Schlüssel können aus unterschiedlichen Wertebereichen
gebildet werden, z. B. 64-Bit-Ganzzahl, wobei Eindeutigkeit pro
Tabelle oder für die gesamte Datenbank gewählt werden kann. Ist Eindeutigkeit
über mehrere Datenbanken gefordert, weil diese synchronisiert werden,
bietet sich der GUID 2 -Datentyp an, der aber mehr Speicher benötigt (128
Bit) und somit die Indizes vergrößert (vgl. [Nil02]).
Weiters ist zu unterscheiden, wo und zu welchem Zeitpunkt die Schlüsselwerte
generiert werden. Einige RDBMS bieten dafür spezielle Mechanismen
wie Sequence (z. B. ORACLE) oder Identity Field (z. B. Microsoft SQL-
Server). Das Identity-Field des Microsoft SQL-Server hat bei Verwendung
mit einem O/R-Mapping-Framework den Nachteil, dass die neue ID erst
beim Einfügen in die Datenbank generiert wird. Soll z. B. ein neuer Auftrag
gespeichert werden, muss zuerst der Order-Datensatz gespeichert werden,
danach muss die vom RDBMS generierte ID mit einer zusätzlichen Datenbankoperation
ausgelesen werden, damit diese für den nächsten Schritt, das
Speichern der Auftragspositionen als Fremdschlüssel (Foreign key, FK) zur
2 Global Unique Identifier

2. Grundlagen 8
Verfügung steht. Dadurch werden zusätzliche zeitaufwändige Datenbankzugriffe
notwendig.
Wesentlich effizienter ist die in ORACLE verfügbare Sequence. Es kann
vorab eine beliebige Anzahl von IDs angefordert werden, die vom ORM sukzessiv
für neue Objekte vergeben werden bis sie aufgebraucht sind. Je mehr
Werte auf einmal angefordert werden, umso weniger Datenbankzugriffe sind
insgesamt dafür notwendig, aber umso mehr IDs werden im Durchschnitt
verschwendet. Einmal angeforderte IDs, sollten sie nicht aufgebraucht werden,
weil die Applikation vorher beendet wurde, können nicht zurückgegeben
werden und sind damit endgültig verloren. Bei einem ausreichend großen
Wertebereich, z. B. 64-Bit-Ganzzahl, stellt das in der Praxis üblicherweise
kein Problem dar.
Wird der Sequence-Mechanismus vom verwendeten RDBMS nicht zur
Verfügung gestellt, kann diese Funktion leicht nachgebildet werden. Eine eigene
Tabelle enthält eine Spalte und einen Datensatz mit der bisher höchsten
vergebenen ID. Soll die ID pro Tabelle eindeutig sein, wird eine weiteres Attribut
mit dem Tabellennamen und für jede Tabelle ein Datensatz benötigt.
Der Wert erhöht sich jeweils um die Anzahl angeforderter IDs. Das Anfordern
der IDs muss in einer eigenen Transaktion durchgeführt werden, da
ansonsten Optimistic Offline Lock (siehe Unterabschnitt 2.2.6) nicht funktionieren
würde.
GUIDs können direkt vom O/R-Mapping-Framework generiert werden
und benötigen daher keine zusätzlichen Datenbankzugriffe.
Für die Verwendung mit einem O/R-Mapping-Lösung sind deshalb einfache
künstliche Schlüssel, die per Sequence-Mechanismus generiert werden
sowie GUID oft die beste Lösung.
2.2.2 Beziehungen
Beziehungen zwischen Objekten sind unidirektional und werden mit Datenkomponenten,
die ein weiteres Objekt referenzieren, dargestellt (1:1). Mehrere
Objekte gleichen Typs werden referenziert, indem eine Behälterklasse als
Datenkomponente verwendet wird (1:n). Bidirektionale Beziehungen werden
als zwei unidirektionale Beziehungen abgebildet. Mit zwei 1:n-Beziehungen
kann eine m:n-Beziehung erstellt werden. Eine Objektreferenz kann Objekte
jener Typen referenzieren, die dem Typ der Datenkomponente oder einem
davon abgeleiteten Typ entsprechen und sind damit polymorph.
Beziehungen im Relationenmodell werden durch Attribute abgebildet.
Der Primärschlüssel einer Tabelle wird als Fremdschlüssel in der referenzierten
Tabelle verwendet. Die Datensätze beider Tabellen sind referenziert,
wenn Primärschlüssel und Fremdschlüssel die gleichen Werte enthalten.
Grundsätzlich bietet das Relationenmodell nur bidirektionale 1:n-Beziehungen,
die mit Hilfe von Einschränkungen (Constraints) auf 1:1 beschränkt
werden können. Mit einer zusätzlichen Beziehungstabelle, zu denen zwei Ta-

2. Grundlagen 9
bellen eine 1:n-Beziehung definieren, wird eine m:n-Beziehung abgebildet.
Dieses Behelfskonstrukt ist bei m:n-Beziehungen zwischen Objekten nicht
notwendig. Für Polymorphismus werden im Relationenmodell keine speziellen
Konstrukte angeboten, die Funktionalität kann aber auf verschiedene
Weise nachgebildet werden und erfordert in erster Linie entsprechend
gestaltete Abfragen. Weiterführende Informationen dazu finden sich unter
„Foreign Key Mapping“ in [FRF02, S. 136] für 1:n-Beziehungen sowie unter
„Association Table Mapping“ [FRF02, 248] für m:n-Beziehungen.
2.2.3 Eingebetteter Wert (Embedded Value)
Objekte sind oft feingranularer als Datenbanktabellen (Fine-grained object
model [KBK08]) um Daten und zugehöriges Verhalten sauber zu kapseln. So
kann es sinnvoll sein, beispielsweise bei einem Customer-Objekt die Address-
Properties in ein eigenes Address-Objekt auszulagern, das vom Customer-
Objekt nur referenziert wird. Im relationalen Modell bietet diese Aufteilung
keinen Vorteil. Dort gibt es nur Daten ohne Verhalten, und daher keine Notwendigkeit
für Kapselung. Würden die Objekte in unterschiedlichen Tabellen
abgebildet, müssten bei Abfragen die Datensätze aus unterschiedlichen
Tabellen wieder zusammengeführt werden. Das ist zeitintensiv und deshalb
nach Möglichkeit zu vermeiden. Die Properties des Address-Objektes sollen
daher in die Customer-Tabelle eingebettet werden.
Unter [FRF02, S. 268] wird auf diese Funktionalität ausführlich eingegangen.
2.2.4 Vererbung
Das Relationenmodell in RDBMS sieht keine Vererbung vor, daher werden
Strategien benötigt, um Vererbungshierarchien in Datenbanken abzubilden.
Es stehen drei Möglichkeiten zur Auswahl, bei denen es unterschiedliche
Vor- und Nachteile abzuwägen gilt. Die Abbildung einer Klassenhierarchie
muss nicht auf eine dieser Strategien beschränkt bleiben. Für Teilhierarchien
können unterschiedliche Varianten verwendet werden.
Vererbungshierarchie in einer Tabelle (Single Table Inheritance)
Bei Vererbungshierarchie in einer Tabelle (Single Table Inheritance) wird die
gesamte Hierarchie in einer Tabelle abgelegt (siehe Abbildung 2.1). Jedes
Objekt wird durch einen Datensatz repräsentiert, wobei nur die Attribute
befüllt werden, die in der konkreten Klasse vorkommen. Die restlichen Attribute
bekommen den Wert null. Das heißt, dass alle zu persistierenden
Properties der Klassen der Hierarchie als Attribut in der Tabelle vorkommen.
Zusätzlich wird ein Diskriminator benötigt, der die konkrete Klasse
identifiziert, die beim Laden aus einem Datensatz erzeugt werden soll.

2. Grundlagen 10
club
Footballer
name
Player
Cricketer
batting average
Bowler
bowling average
Abbildung 2.1: Single Table Inheritance [FRF02, S. 278].
«table»
Players
name
club
batting average
bowling average
type
Der Vorteil ist, dass für die gesamte Hierarchie nur eine Tabelle benötigt
wird. Beim Laden entfällt das zusammenführen (Join) mehrerer Tabellen,
Abfragen sind entsprechend effizient. Polymorphe Relationen können damit
abgebildet werden.
Nachteilig wirkt sich aus, dass in der Tabelle die Zahl der Attribute
schnell anwachsen kann. Definieren die abgeleiteten Klassen eigene Properties,
werden in der Tabelle entsprechend viele Spalten benötigt, obwohl
bei jedem einzelnen Datensatz nur ein Teil davon belegt wird. Außer bei
den Attributen der Basisklasse ist es daher nicht möglich, „NOT NULL“-
Einschränkungen zu definieren. Werden in verschiedenen Subklassen gleichnamige
Properties eingeführt, entstehen Konflikte die aufgelöst werden müssen,
z. B. durch voranstellen eines spezifischen Präfixes für jede Subklasse.
Vererbung mit einer Tabelle pro Klasse (Class Table Inheritance)
Bei Vererbung mit einer Tabelle pro Klasse wird für jede Klasse der Hierarchie
eine Tabelle erstellt, wobei für die in einer Subklasse zusätzlich definierten
Properties eine eigene Tabelle verwendet wird (siehe Abbildung 2.2).
Ein Vorteil gegenüber Vererbungshierarchie in einer Tabelle ist, dass keine
Spalten ungenützt bleiben. Nachteilig wirkt sich aus, dass beim Laden die
Tabellen wieder zusammengeführt werden müssen. Wobei pro Datensatz, abhängig
vom konkreten Typ, unterschiedliche Tabellen zu kombinieren sind.
Vor allem bei Klassenhierarchien mit mehr als drei Tabellen beeinträchtigt
das die Geschwindigkeit, da RDBMS üblicherweise nur für Joins mit bis zu
drei Tabellen optimiert sind.

2. Grundlagen 11
club
club
Footballer
Footballer
name
Player
Cricketer
batting average
Bowler
bowling average
Abbildung 2.2: Class Table Inheritance [FRF02, S. 285].
name
Player
Cricketer
batting average
Bowler
bowling average
«table»
Footballers
club
«table»
Cricketers
batting average
«table»
Bowlers
bowling average
«table»
Players
name
«table»
Footballers
name
club
«table»
Cricketers
name
batting average
«table»
Bowlers
name
batting average
bowling average
Abbildung 2.3: Concrete Table Inheritance [FRF02, S. 293].
Vererbung mit einer Tabelle pro konkreter Klasse (Concrete Table
Inheritance)
Bei Vererbung mit einer Tabelle pro konkreter Klasse (Concrete Table Inheritance)
wird für jede konkrete Klasse der Hierarchie eine Tabelle angelegt
(siehe Abbildung 2.3). Alle Properties der konkreten Klasse sowie die aller
direkten und indirekten Superklassen werden in dieser Tabelle abgelegt.

2. Grundlagen 12
Die Properties der Superklassen kommen daher in allen Tabellen vor, deren
Klassen von dieser Superklasse ableiten.
Wie bei Vererbung mit einer Tabelle pro Klasse werden bei jedem Datensatz
alle Attribute belegt, weiters werden beim Laden keine Joins benötigt.
Wesentliche Nachteile sind, dass bei Abfragen auf eine Basisklasse Unions
notwendig sind, sowie bei Änderungen an Attributen einer Basisklasse,
die Änderungen in allen Tabellen abgeleiteter Klassen durchgeführt werden
müssen.
2.2.5 Arbeitseinheit (Unit of Work)
Wird jede einzelne Datenänderung an einem Objekt im Speicher einzeln
in die Datenbank geschrieben, resultiert das in einer Unmenge von Datenbankzugriffen.
Dadurch wird die Skalierbarkeit drastisch eingeschränkt, auch
deshalb, weil eine Datenbanktransaktion vom ersten bis zum letzten Zugriff
offen gehalten werden muss. Dieses Problem kann umgangen werden, indem
die Änderungen im Arbeitsspeicher mitprotokolliert und dann gebündelt an
die Datenbank abgesetzt werden („Unit of Work“ [FRF02, S. 184]).
Eine Arbeitseinheit muss von den Datenänderungen erfahren, um sie
protokollieren zu können. Entweder wird die Arbeitseinheit explizit von jeder
Änderung benachrichtigt oder es werden Mechanismen implementiert, mit
denen die Arbeitseinheit Änderungen selbständig eruieren kann.
Explizite Benachrichtigungen haben den Nachteil, dass sie leicht vergessen
werden. Sollen die Objekte selbständig Änderungen melden, müssen diese
Kenntnis vom Abbildungs-Framework haben, womit die Unabhängigkeit
von der Persistenzschicht (siehe Unterabschnitt 2.2.8) aufgeweicht wird.
Werden lesende Zugriffe auf die Datenbank mit der Arbeitseinheit kombiniert,
können Kopien der zurückgelieferten Objekte zum späteren Vergleich
behalten werden, um damit Änderungen automatisch festzustellen
(in [FRF02, S. 187] als „Unit of Work Controller“ bezeichnet). Der Nachteil
hierbei ist, dass alle Objekte doppelt im Speicher angelegt werden.
Eine alternative Möglichkeit ist, dass die Zugriffsoperationen von den
Entitätsklassen abgeleitete Klassen liefern (Proxy [GHJV04, S. 254]), die
die Properties überschreiben und so erweitern, dass die Arbeitseinheit von
Änderungen benachrichtigt wird.
Durch das Zusammenfassen aller Änderungen einer Geschäftstransaktion
geht die Reihenfolge der Änderungen verloren. Wird nicht eine bestimmte
Reihenfolge eingehalten besteht die Gefahr, dass die referentielle Integrität
verletzt wird, oder es zu Deadlocks kommt. Aufgabe der Arbeitseinheit ist
es daher, vor dem Absetzen der DMS-Statements an die Datenbank die
Reihenfolge so zu sortieren, dass alle Abhängigkeiten aufgelöst sind.

2. Grundlagen 13
2.2.6 Nebenläufigkeit (Concurrency)
Optimistische verbindungslose Sperre (Optimistic Offline Lock) [FRF02, S.
416] ist eine Methode, die Dateninkonsistenzen bei konkurrierenden Datenänderungen
gleichzeitig ablaufender Transaktionen verhindert.
Realisiert wird diese Konflikterkennung durch ein zusätzliches Attribut
in jeder Tabelle, das bei jeder Datenänderung inkrementiert wird und somit
die Version eines Datensatzes definiert. Vor dem Schreiben der Änderung
wird geprüft, ob die Version in der Datenbank noch mit der des Lesezeitpunktes
übereinstimmt. Ist sie unverändert, wird die Änderung durchgeführt.
Wurde der Datensatz in der Zwischenzeit von einer anderen Transaktion
geändert oder gelöscht, besteht ein Konflikt und die laufende Transaktion
muss mit einem Rollback abgebrochen werden.
Optimistische Verbindungslose Sperre lässt mehr gleichzeitige Datenzugriffe
zu als Datenbanktransaktionen und verbessert damit den Durchsatz.
Nachteilig wirkt sich aus, dass erst am Ende der Geschäftstransaktion
geprüft wird, ob ein Konflikt besteht. Dadurch kann es passieren, dass
zeitaufwändig erfasste Eingaben verworfen und von Neuem erstellt werden
müssen. Das kann zu Akzeptanzproblemen bei den Anwendern führen.
2.2.7 Laden bei Bedarf (Lazy Loading)
Für jedes Transaktionsskript (siehe Unterabschnitt 2.1.1) kann eine angepasste
SQL-Abfrage erstellt werden, die genau jene Daten liefert, die für
die Transaktion benötigt werden, mit Hilfe von entsprechenden Joins und
Projektionen. Ein Data Mapper ist allerdings vollkommen unabhängig von
der Geschäftslogik. Unter dieser Voraussetzung lautet ein einfacher Ansatz,
jedes angeforderte Objekt einzeln aus der Datenbank zu laden.
Wird beispielsweise auf eine Auftragsposition zugegriffen, werden oft
auch die zugehörigen Auftragspositionen benötigt. Bei einem darauf folgenden
Zugriff auf jede Auftragsposition würde dadurch ein neuerlichen Datenbankzugriff
verursacht, obwohl es wesentlich effizienter wäre, den Auftrag
mit allen Auftragspositionen mit einem Zugriff (z. B. Join) zu laden.
Würden bei einem Zugriff auf einen Datensatz alle Detaildatensätze automatisch
mit geladen, müssten mit einem Zugriff auf einen Kunden alle
erteilten Aufträge dieses Kunden und alle zugehörigen Positionsdaten und
die darin referenzierten Artikeldaten usw. geladen werden. Das würde dazu
führen, dass der Zugriff auf einen Kunden beinahe die gesamte Datenbank
in den Arbeitsspeicher lädt. Also muss der Automatismus irgendwo unterbrochen
werden. Dieses Problem kann mittels „Lazy Loading“ [FRF02, S.
200] gelöst werden.

2. Grundlagen 14
2.2.8 Unabhängigkeit der Entitätsklassen von der Persistenzschicht
(Persistence Ignorance)
Um den „Domain-Layer“ [Eva03, S. 75] von Infrastrukturcode freizuhalten,
also eine saubere Trennung zwischen den Schichten beizubehalten, ist
es wichtig, die Entitätsklassen weitgehend unabhängig vom O/R-Mapping-
Framework zu halten. Diese Trennung wird angestrebt, um das Designprinzip
„Separation of concerns“ [Dij82] möglichst sauber umsetzen zu können.
Entitätsklassen sollen nach Möglichkeit keine Kenntnis davon haben,
dass sie überhaupt persistiert werden. Diese Anforderung wird üblicherweise
als „Persitence Ignorance“ [Nil06, S. 182] bezeichnet. Klassen, die frei
von Persistierungscode sind, werden als POCO (Plain old CLR Object oder
unter Java als POJO) bezeichnet. Verschiedene Anforderungen an den O/R-
Mapping-Framework, z. B. Setzen von privaten Properties beim Wiederherstellen
von persistenten Objekten oder automatische Änderungsverfolgung,
widersprechen dieser Anforderung.
Es gibt verschiedene Ansätze, Unabhängigkeit von der Persistenzschicht
zu realisieren, Kompromisse sind aber unumgänglich. Teilweise wird Reflection
verwendet, um auf private Properties zuzugreifen oder ein Konstruktor
wird gefordert, der für alle Properties entsprechende Parameter vorsieht.
Müssen Entitätsklassen ein bestimmtes Interfaces implementieren, um
den Zugriff auf Internas der Objekte zu ermöglichen, wird das auch als IPO-
CO (Interface-POCO) bezeichnet [34, 50].
Unumgänglich ist weiters die Implementierung einer Property für den
Primärschlüssel. Vollständige Unabhängigkeit von der Persistenzschicht ist
daher kaum realisierbar.
2.2.9 Konfiguration
Die in dieser Arbeit untersuchten Produkte sind Meta Data Mapper (siehe
Unterabschnitt 2.1.3). Das bedeutet, die Abbildung der Klassen und Objekte
auf die Datenbank wird per Metadaten definiert.
Metadaten können als XML-Dateien vorliegen oder als Attribute in den
Entitätsklassen eingebettet sein. Je nach Implementierung werden diese Metadaten
zur Laufzeit ausgewertet und die Abbildung entsprechend durchgeführt
oder es wird zur Kompilierzeit expliziter Code für die Abbildung
generiert. Die erste Variante verwendet üblicherweise Reflection für die Objekterzeugung
und den Zugriff auf die Properties.
Reflection gilt, im Verhältnis zu direkten Aufrufen, als sehr langsam,
wobei dieser Overhead durch Optimierungen weitgehend eliminiert werden
kann. In ausgelagerten oder anderen sicherheitskritischen Umgebungen kann
Reflection eingeschränkt sein, wodurch darauf basierende Produkte nicht
eingesetzt werden können.

2. Grundlagen 15
2.2.10 Weitere Aufgaben einer O/R-Mapping-Lösung
Zu einer leistungsfähigen O/R-Mapping-Lösung gehören weitere grundlegende
Funktionen. Einige davon betreffen den Entwickler direkt, andere arbeiten
unbemerkt im Hintergrund. Aus Platzgründen kann in dieser Arbeit
nicht näher darauf eingegangen werden. Der Vollständigkeit halber sollen
einige trotzdem kurz angesprochen werden.
Abfragen (Query)
O/R-Mapping-Lösungen bieten zumindest eine, oft auch mehrere Möglichkeiten,
Abfragen abzusetzen. Zur Anwendung kommen u. a. Abfragesprachen,
die an die für Objektdatenbanken entworfene Object Query Language
(OQL) [35] angelehnt sind. Solche Abfragen werden wie in SQL als Zeichenkette
übergeben.
Typsichere Varianten wie das unter [FRF02, S. 316] beschriebene „Query
Object“, ermöglichen Abfragekriterien als Objektgraph zu konstruieren.
Seit der .NET-Version 3.5 ist die objektorientierte und typsichere Abfragesprache
LINQ [31] in die .NET-Sprachen (C#, VisualBasic.NET) integriert.
Der Trend geht dahin, dass LINQ- auch von O/R-Mapping-Lösungen
als Abfragesprache unterstützt wird.
Caching
Um das aufwändige Laden der Daten aus der Datenbank sowie das Erzeugen
der Objekte zu minimieren, werden üblicherweise verschiedene Caching-
Strategien unterstützt. Die Palette reicht von einem fixen integrierten Cache
bis zu per Konfiguration einbindbaren Zusatzmodulen (auch von Drittherstellern)
mit speziellen Cachingstrategien, wie Unterstützung für verteilte
Cache-Lösungen für Umgebungen mit mehreren Applikationsservern.
Stored Procedures
Der Zugriff auf die Datenbank über Stored Procedures kann u. U. durch
Einsparen von Roundtrips oder Nützen RDBMS-interner Optimierungen,
Geschwindigkeitsvorteile bringen. Es wird aber auch die Wartbarkeit von
Programmen erschwert, da der Programmcode auf unterschiedliche Entwicklungsumgebungen
und Programmiersprachen verteilt wird. Designentscheidungen,
firmeninterne Richtlinien oder der gemeinsame Zugriff auf Legacy-
Datenbanken mit anderen Applikationen, die auf Stored Procedures aufsetzen,
können das Zugreifen auf Stored Procedures erforderlich machen. Deshalb
bieten O/R-Mapping-Lösungen oft entsprechende Möglichkeiten an.

2. Grundlagen 16
Zusammengesetzte Schlüssel
Für den Einsatz mit einem O/R-Mapping-Framework ist es aus verschiedenen
Gründen empfehlenswert, ein Surrogat als Primärschlüssel zu verwenden
(siehe auch Unterabschnitt 2.2.1). Trotzdem kann es erforderlich sein,
mit zusammengesetzten Schlüsseln zu arbeiten, wenn bestehende Datenbankschemas
verwendet werden müssen. Eine entsprechende Unterstützung
durch die O/R-Mapping-Lösung sollte daher bei entsprechenden Anforderungen
geprüft werden.
Datenbindung
Um die aus der Datenbank geladenen Daten per Datenbindung von Steuerelementen
der Benutzeroberfläche darstellen zu lassen, sind entsprechende
Vorkehrungen zu treffen. Die Entitätsklassen können meist nach Bedarf gestaltet
werden. Die gegebenenfalls notwendige Implementierung der Anforderungen
des .NET-Frameworks 3 , liegt daher weitgehend in der Verantwortung
des Entwicklers. Die Behälterklassen werden oft vom O/R-Mapping-
Framework vorgegeben, da sie z. B. für Laden bei Bedarf spezielle Mechanismen
implementieren. Hier kann es schwierig werden, die Anforderungen
des .NET-Frameworks 4 zu implementieren.
3-Tier bzw. n-Tier-Architektur
Nicht jeder mögliche Mechanismus zum Verfolgen von Datenänderungen
(change tracking) funktioniert ohne weiteres, wenn die Objekte über Prozessgrenzen
hinaus übertragen werden (z. B. ASP.NET Viewstate, Client-Tier in
3-Tier-Applikationen). Eine Diskussion zu diesem Thema ist z. B. unter [6]
zu finden.
3 z. B. INotifyPropertyChanged oder PropertyDescriptor
4 z. B. ITypedList

Kapitel 3
Evaluierung
In diesem Abschnitt werden die für das Erstellen der Beispielapplikation
relevanten Anforderungen an O/R-Mapping-Frameworks und deren Umsetzung
in den einzelnen Produkten (ADO.NET Entity Framework, Genome
und NHibernate) untersucht und deren Verwendung beschrieben.
3.1 Verglichene Produkte
Alle untersuchten Produkte weisen bereits eine lange Entwicklungsgeschichte
auf, auch wenn das Microsoft ADO.NET Entity Framework erst vor kurzem
erschienen ist. Dieser Abschnitt soll einen Eindruck davon vermitteln, wie
sich die Produkte entwickelt haben und wie sie am Markt positioniert sind.
3.1.1 ADO.NET Entity Framework
Beim Erscheinen der .NET-Plattform von Microsoft im Jahr 2002 wurde
ADO.NET und Datasets als große Neuerung und Verbesserung gegenüber
ADO (Active Data Objects) angekündigt [MN02, S. 47] [RNG + 04, S. 514].
Schon damals war bekannt, dass mit O/R-Mapping-Lösungen komfortablere
Möglichkeiten für die Peristierung von Objekten existieren, wobei aktuelle
O/R-Mapping-Lösungen für .NET durchwegs auf ADO.NET, aber nicht auf
Datasets aufbauen.
Im Jahr 2001 wurde von Microsoft erstmals ein entsprechendes Produkt,
unter der Bezeichnung ObjectSpaces, angekündigt [Esp04] [8]. Es wurde von
Microsoft sogar eine Vorabversion für interessierte Entwickler bereitgestellt.
Während im Jahr 2005 die baldige Auslieferung erwartet wurde, kündigte
Microsoft an, dass ObjectSpaces zugunsten der neuen Technologie, dem
ADO.NET Entity Framework, LINQ 1 sowie LINQ to SQL [1,5,13,31] aufgegeben
wurde. Es kamen allerdings einige Zweifel auf, ob Microsoft wirklich
1 Language INtegrated Query
17

3. Evaluierung 18
in der Lage und auch Willens war, eine eigene O/R-Mapping-Lösung zu
entwickeln [Sch07].
Gegen Ende des Jahres 2007 hat Microsoft als Teil des neuen .NET-
Frameworks Version 3.5, LINQ und LINQ to SQL ausgeliefert, wobei LINQ
to SQL eine minimalistische O/R-Mapping-Lösung darstellt [Sch08]. Die
Auslieferung der angekündigten flexiblen, leistungsfähigen und datenbankunabhängigen
O/R-Mapping-Lösung ADO.NET Entity Framework, wurde
ein weiteres Mal verschoben. Im August 2008 wurde mit dem Microsoft
Visual Studio 2008 Service Pack 1 und .NET Framework 3.5 Service Pack
1 endlich eine, von vielen seit Jahren erwartete, erste Version einer O/R-
Mapping-Lösung von Microsoft fertiggestellt und gemeinsam mit anderen
Neuerungen und Erweiterungen als Service Pack für Visual Studio und .NET
angeboten [26, 28–30, 56].
Seit Microsoft Vorabversionen des ADO.NET Entity Framework bereitstellt,
gibt es Kritiker, die Schwächen in der Architektur und der gebotenen
Funktionalität bemängeln [64]. Auch für einen Hersteller wie Microsoft ist
es unmöglich, alle Anwender vollkommen zufrieden zu stellen, doch gestehen
sogar Mitglieder des Entwicklerteams Unzulänglichkeiten ein [15, 17].
Die Laufzeitkomponenten des ADO.NET Entity Framework sind Teil des
.NET-Framework Version 3.5 Service Pack 1, die zugehörige Entwicklungswerkzeuge
sind Teil des Service Pack 1 für Visual Studio 2008. Mit der Shared
Source-Initiative [23] gewährt Microsoft für Teile des .NET-Frameworks
Einblick in den Quellcode. Das Entity Framework ist, zumindest derzeit,
noch davon ausgenommen.
Kompetente Unterstützung bei eventuellen Problemen erhält man im
MSDN-Produktforum zum ADO.NET Entity Framework [18]. Im rege benutzten
Forum werden viele Probleme diskutiert und mögliche Lösungen
aufgezeigt. Die vorhandene Dokumentation ist leider nicht auf dem letzten
Stand. Sie enthält Dokumente, die nicht vorhandene Funktionen beschreiben,
oder sich auf Vorabversionen bezieht. Eine schnell größer werdende
Anzahl an Blogeinträgen und anderen Onlineressourcen zum Entity Framework
bieten oft die gesuchten Informationen. Weiterführende Unterstützung
bietet der von Microsoft angebotene kostenpflichtige Support.
Microsoft weist immer wieder darauf hin, dass die Einsatzmöglichkeiten
des ADO.NET Entity Framework weiter reichen als die herkömmlicher
O/R-Mapping-Lösungen. Dem EntityDataReader kommt dabei laut Microsoft
eine entscheidende Bedeutung zu. Während beim herkömmlichen Data-
Reader die Daten entsprechend dem Speichermodell strukturiert sind, beziehen
sich Anfragen an den EntityDataReader auf das konzeptionelle Modell.
Der ausschließlich sequentielle Zugriff umgeht die Objekterzeugung durch
die ObjectServices (siehe Abbildung 3.1). Die ObjectServices entsprechen
dabei weitgehend der in Unterabschnitt 2.2.5 beschriebenen Arbeitseinheit.
Wenn die Daten nicht als Objekte benötigt werden, wie das z. B. bei Auswertungen
und Berichten der Fall sein kann, entfällt somit ein beträchtli-

3. Evaluierung 19
Abbildung 3.1: Entity Framework Architektur [21].
cher Verwaltungsaufwand. Die unter dem Projektnamen Astoria entwickelten
ADO.NET DataServices [32, 58], stellen eine erste Lösung dar, die das
konzeptionelle Modell des Entity Framework auf diese Weise nutzen. Die
ADO.NET DataServices ermöglichen den Datenbankzugriff über das HTTP
Protokoll und bauen auf das Entity Framework auf. Die Daten werden als
Datenstrom per HTTP übertragen. Es wäre dabei ineffizient aus den Daten
Objekte zu erzeugen nur um sie danach für die Übertragung zu serialisieren.
3.1.2 Genome
Genome [59] wurde von dem Wiener Softwarehaus TechTalk [60] entwickelt.
Seit 2003 wird Genome als eigenständiges Produkt vertrieben und ist seit
August 2008 in der Version 4.0 erhältlich.
Bei Genome handelt es sich um ein kommerzielles Produkt, das in verschiedene
Editionen zu verschiedenen Preisen angeboten wird. Die Professio-

3. Evaluierung 20
nal-Edition bietet den vollständigen Funktionsumfang.
Eine im Funktionsumfang etwas eingeschränkte Express Edition unterstützt
grundsätzlich nur die verschiedenen Microsoft SQL-Server-Varianten,
kann aber laut TechTalkfür die Unterstützung von Oracle 9i, Oracle 10g und
IBM DB2 aufgerüstet werden. Eine kostenlose Community-Edition für nicht
kommerzielle Softwareentwicklung, sowie eine kostenlose Evaluation-Edition
runden das Angebot ab. Der Quellcode ist über eine entsprechende Lizenz
erhältlich. Die Express-Edition, die laut TechTalk für die meisten Projekte
ausreichen müsste, wird für e 299,- 2 pro Entwickler angeboten. Für die
Professional-Edition liegen die Preise zwischen e 1.170,- und e 1.800,- pro
Entwickler, gestaffelt nach Anzahl der erworbenen Lizenzen. Zu beziehen ist
Genome entweder direkt von TechTalk oder über Vertriebspartner.
Für diese Arbeit wurde von TechTalk freundlicherweise eine Lizenz für
die Community-Edition mit der Laufzeit von einem Jahr zur Verfügung gestellt.
Die Community-Edition entspricht vom Funktionsumfang der Professional-Edition.
Für die erstellte Beispielanwendung wird nur Funktionalität
genutzt, die auch von der Express-Edition geboten wird.
Für die aktuelle Version 4.0 wird .NET 3.5 und Visual Studio 2008 vorausgesetzt,
Vorgängerversionen arbeitet auch mit den früheren .NET- und
Visual Studio-Versionen zusammen.
Für Fragen wurde einige Male auf das kostenlose Support-Forum zurückgegriffen,
das über die Genome-Webseite erreichbar ist. Die Antworten
erfolgten durchwegs innerhalb weniger Stunden und waren kompetent und
ausführlich. Die Dokumentation ist umfangreich, wurde aber für diese Arbeit
zu wenig benötigt, um sie beurteilen zu können.
3.1.3 NHibernate
NHibernate [KBK08] [46] ist eine Portierung der für Java entwickelten und
sehr populären O/R-Mapping-Lösung Hibernate [KB04, Bau06] [41] auf die
.NET-Plattform. Hibernate wurde von Gavin King als quelloffenes Projekt
initiiert [62]. Auf SourceForge.net reichen die Informationen bis zur Version
0.8 im Dezember 2001 zurück [61]. Gavin King wurde später von der Firm
JBoss [44], das mittlerweile zu RedHat [45] gehört, angestellt, um Hibernate
weiterzuentwickeln [65]. Tom Barret begann, ausgehend von der Version
2.1, Hibernate nach .NET zu portieren [3]. Erste Einträge dazu finden sich
ebenfalls auf SourceForge.net, datiert mit März 2003. Später wurden auch
führende NHibernate-Entwickler von JBoss angestellt, um die weitere Entwicklung
hauptberuflich zu betreiben [3].
Im August 2008 wurde die NHibernate-Version 2.0 freigegeben, die vom
Funktionsumfang weitgehend Hibernate 3.2 entsprechen soll. LINQ-Support
für NHibernate ist schon längere Zeit in Arbeit und wird für die nächs-
2 Auf der Webseite ausgewiesene Listenpreise

3. Evaluierung 21
te Version erwartet [43]. Für aktuelle NHibernate-Versionen ist .NET 2.0
Mindestvoraussetzung. Weiters soll NHibernate auch mit der quelloffenen
.NET-Implementierung Mono [33] zusammenarbeiten.
Dass NHibernate von vielen Entwicklern eingesetzt wird, ist an der Anzahl
an Einträgen in verschiedensten Foren und Blogs zu erkennen. Für die
meisten auftretenden Fragen und Probleme sind daher bereits Antworten
vorhanden. Die große Anzahl an Einträgen erschwert es oft, zu konkreten
Problemen die passenden Einträge auch zu finden. Die Dokumentation ist
für eine quelloffenes Produkt umfangreich und weitgehend leicht zu verstehen.
Professioneller Support für NHibernate wird von RedHat angeboten.
3.2 Funktionalität
3.2.1 Metadaten
Bei allen drei Testkandidaten muss dem O/R-Mapping-Framwork mittels
Metadaten (siehe Unterabschnitt 2.1.3) vorgegeben werden, welche Klassen
für die Persistierung vorgesehen sind und wie diese Klassen und ihre Beziehungen
untereinander behandelt werden sollen. Beim ADO.NET Entity
Framework und bei NHibernate werden diese Informationen grundsätzlich
erst zu Laufzeit benötigt. Die Metadaten können zur Laufzeit, vor der Weitergabe
an das O/R-Mapping-Framework, generiert und auch manipuliert
werden. ADO.NET Entity Framework kann aus den Metadaten den Quelltext
für die Entitätsklassen automatisch generieren, auch dafür müssen die
Metadaten bereits zur Entwicklungszeit vorliegen. Genome generiert aus
den Metadaten Quelltext, der die Persistierung und Wiederherstellung der
Objekte vornimmt und benötigt die Metadaten daher zwingend zur Entwicklungszeit.
Genome und das Entity Framework validieren die Metadaten
schon zur Übersetzungszeit, bei NHibernate treten eventuelle Fehler erst zur
Laufzeit zu Tage.
Alle untersuchten Produkte erwarten die Metadaten im XML-Format.
NHibernate ermöglicht, die Einbettung der Metadaten als Attribute in die
Entitätsklassen, aus denen zur Laufzeit das geforderte XML-Format generiert
wird. NHibernate und Genome benötigen für jede zu persistierende
Entitätsklasse in den Metadaten ein Element, das definiert, wie diese Klasse
und die Beziehungen abgebildet werden sollen. Die Metadaten können
auf mehrere Dateien aufgeteilt werden, wobei eine Datei einen oder mehrere
Elemente enthalten kann. Beim ADO.NET Entity Framework wurde hier
ein abweichender Ansatz gewählt.
Die Metadaten des ADO.NET Entity Framework bestehen aus drei Teilen,
die gemeinsam das Entity Data Model (EDM) bilden [Pap07] [20,25,27].
Ein Teil, das Konzeptionelle Modell (Conceptual Schema), beschreibt die
Struktur der Entitätsklassen und deren Beziehungen untereinander. Das
Speichermodell (Storage Schema), gibt die Struktur des Datenbankschemas

3. Evaluierung 22
wider. Die Abbildungsdefinition (Mapping Specification) ist der dritte Teil,
der beschreibt, wie das konzeptionelle Modell auf das Speichermodell abgebildet
wird. Das Entity Data Model wird zusammen mit Daten für das
grafische Designer-Werkzeug in einer Datei mit der Endung .edmx abgelegt.
Listing 3.1 bis Listing 3.5 zeigen die Teile einer minimalistischen edmx-Datei,
mit der eine einzelne Klasse „Country“ ohne Beziehungen abgebildet wird.
Listing 3.1 zeigt dabei das Gerüst, das die einzelnen Abschnitte umgibt. In
Listing 3.2 bis Listing 3.4 sind diese Abschnitte der Metadaten dargestellt.
Diese drei Abschnitte sind ähnlich strukturiert. Das konzeptionelle Modell
sowie das Speichermodell enthalten jweils eine Definition für einen Entity-
Container, der einer Arbeitseinheit (siehe Unterabschnitt 2.2.5 entspricht.
Der EntityContainer enthält EntitySet- und AssociationSet-Definitionen,
die im Speichermodell den Tabellen und referentiellen Beziehungen zwischen
den Tabellen entsprechen, im konzeptionellen Modell jedoch den Entitätsklassen
entsprechen. AssociationSet-Definitionen kommen in den angeführten
Quelltexten nicht vor, da keine Beziehungen definiert wurden. In der Abbildungsdefinition
wwerden über EntityContainerMapping, EntitySetMapping
und AssociationSetMapping die Elemente aus dem konzeptionellen Modell
den entsprechenden Elementen aus dem Speichermodell zugeordnet. Die
EntityType-Definitionen geben die Struktur der Tabellen und Entitätsklassen
wider, auf die sich die EntitySet-Definitionen im konzeptionellen sowie
im Speichermodelle beziehen. Die EntityTypeMapping-Elemente in der Abbildungsdefinition
legen wiederum fest welche EntityType-Elemente aus dem
konzeptionellen Modell auf welche EntityType-Elemente im Speichermodell
abgebildet werden. Für die Definition des EntityDataModel stehen noch einige
weitere Elemente zur Verfügung, etwa um Vererbung festzulegen. Beispielhafte
Daten des Designer-Werkzeugs werden in Listing 3.5 gezeigt.
Listing 3.1: ADO.NET Entity Framework edmx-Datei.
1
2
3
4
5
6
7
8
9
10
Zur Laufzeit müssen die Metadaten als drei eigenständige XML-Dateien, mit
den Endungen .csdl 3 , .ssdl 4 und .msl 5 vorliegen. Beim Übersetzen werden
3 Conceptual Schema Definition Language
4 Storage Schema Definition Language
5 Mapping Specification Language

3. Evaluierung 23
diese Dateien aus der .edmx-Datei generiert [11].
Listing 3.2: Der „CSDL content“ aus Listing 3.1, Zeile 6.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Listing 3.3: Der „SSDL content“ aus Listing 3.1, Zeile 5.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

3. Evaluierung 24
Listing 3.4: Der „C-S mapping content“ aus Listing 3.1, Zeile 7.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Listing 3.5: Ausschnitt „EF Designer content“ aus Listing 3.1, Zeile 9.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Bei Genome und NHibernate werden diese Metadaten wesentlich kompakter
dargestellt. So haben die Metadaten für das Entity Framework in der
erstellten Beispielanwendung in etwa den dreifachen Umfang im Vergleich

3. Evaluierung 25
zu den anderen beiden Produkten. Derselbe Anwendungsfall, den Listing 3.1
bis Listing 3.5 für das Entity Framework dargestellen, wird für NHibernate
mit Listing 3.6 bzw. für Genome mit Listing 3.7 umgesetzt. Für jede Entitätsklasse
die persitiert werden soll, wird ein class-Element erstellt. Mit
einem Attribut wird der Name der Tabelle festgelegt werden, in die die
Entitätsklasse persistiert werden soll. Sind Tabellenname und Klassenname
identisch wie im angeführten Beispiel, kann diese Angabe entfallen. Das
id-Element definiert das Id-Attribut bzw. den Primärschlüssel(siehe Unterabschnitt
2.2.1). Mit dem version-Element wird eine Property für optimistische
verbindungslose Sperre (siehe Unterabschnitt 2.2.6) festgelegt. Die
Abbildung einzelner Properties der Entitätsklassen auf Attribute der Tabellen
erfolgt über property-Elemente, wobei die Namen der Tabellenattribute
nur anzugeben sind, wenn diese von den Propertynamen abweichen.
Listing 3.6: NHibernate Metadaten.
1
2
7
8
11
15
16 RowId
17 NextValue
18 10
19
20
21
22
25
26
30
31
35
36

3. Evaluierung 26
Die Metadaten sind bei Genome ähnlich strukturiert wie bei NHibernate.
Die Elemente Type, PrimaryKey, OptimisticLock und Member in Genome
entsprechen in etwa den NHibernate-Elementen class, id, version und property.
Das Element CodeGeneratedProxy weist Genome an, zu den abstrakten
Entitätsklassen Quelltext für konkrete Implementierungen zu generieren.
Es ist bei allen Entitätsklassen anzugeben, außer es handelt sich um abstrakte
Basisklassen von denen keine Objekte erzeugt werden sondern von denen
nur weiter abgeleitet wird, wie das z. B. bei den Klassen Item oder Contact
in der Beispielimplementierung der Fall ist (siehe Kapitel 4).
Listing 3.7: Genome Metadaten
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 Id
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
3.2.2 Objektidentität
Wie im Unterabschnitt 2.2.1 beschrieben sind einfache künstliche Schlüssel,
die per Sequence-Mechanismus generiert werden, eine effiziente Lösung zum
Erzeugen von Ids für neue Objekte. Noch effizienter können GUID-Werte

3. Evaluierung 27
generiert werden, da das ohne jeden Datenbankzugriff erfolgen kann. Ids
vom Typ GUID haben aber den Nachteil, dass sie wesentlich mehr Speicherplatz
(16 Bytes) benötigen und dadurch die Indizes vergrößern (siehe
Unterabschnitt 2.2.1). Alle drei untersuchten Produkte können laut Dokumentation,
GUID als Primärschlüssel ohne weiteres handhaben. Da in der
Beispielanwendung keine besonderen Anforderungen die Verwendung von
GUID rechtfertigen, ist die Wahl auf den Sequence-Mechanismus gefallen,
der nachfolgend näher untersucht wird.
NHibernate unterstützt, abhängig vom eingesetzten RDBMS, mehrere
Varianten. Bei Datenbanken wie z. B. Oracle, die selbst einen Sequence-
Mechanismus anbieten, kann NHibernate angewiesen werden, diesen zu verwenden.
Andernfalls genügt es, eine Tabelle mit einem Attribut in der Datenbank
anzulegen, die NHibernate zur Verfügung gestellt wird, um den nächsten
verfügbaren Wert abzulegen. Letztere Variante wurde in der Beispielanwendung
genutzt, da der Microsoft SQL-Server keinen Sequence-Mechanismus
anbietet. Diese Variante bietet höchstmögliche Portabilität, da sie auf
jedes RDBMS identisch abgebildet werden kann. Neben der Effizienz ist das
ein weiterer wesentliche Vorteil.
Listing 3.8: NHibernate Beispiel
1
4
8
9 RowId
10 NextValue
11 10
12
13
14
15
Listing 3.8 zeigt, wie die gewünschte Id-Generierungsvariante in NHibernate
festgelegt wird, die relevanten XML-Elemente sind durch Fettdruck
hervorgehoben. Die ID-Generierung ist für jede abzubildende Klasse einzeln
festzulegen. Der Generierungsalgorithmus heißt in NHibernate „hilo“.
RowId ist der Name der zu verwendenden Tabelle, NextValue der Name
des Attributes in der Tabelle. Die Anzahl der Werte, die bei jedem Zugriff
angefordert werden, wird mit Parameter max_lo festgelegt. Ohne explizite
Definition von table, column und max_lo werden von NHibernate bereitgestellte
Vorgabewerte verwendet. Eine Schwäche dieser Implementierung
ist, dass für jede Klasse ein eigener Zähler im Speicher verwaltet wird. Die
Anzahl verlorener Werte wird dadurch unnötig erhöht.

3. Evaluierung 28
Per Konfiguration bietet ADO.NET Entity Framework die Auswahl zwischen
vier Varianten, um Id-Werte zu generieren. Bei zwei der vier Varianten
wird erwartet, dass die Werte in der Datenbank erzeugt werden. Entweder
ist der Primärschlüssel als ein Attribut des Typs Identity definiert oder die
Werte des Primärschlüssels werden auf eine andere Art in der Datenbank
zugewiesen, z. B. durch Trigger. Wird für den Primärschlüssel der Datentyp
GUID gewählt, übernimmt das Entity Framework die automatische Zuweisung
neuer Werte. Als vierte Variante wird angeboten, dass sich das Entity
Framework nicht um die Generierung kümmert. Damit wird zumindest eine
eigene Implementierung von Clientseitig zugewiesenen Id-Werten ermöglicht.
Für die Beispielanwendung wurde die letzte Variante gewählt, die den
Sequence-Mechanismus nachbildet, wie in Unterabschnitt 2.2.1 beschrieben.
Diese Lösung entspricht in etwa dem bei NHibernate verwendetem HiLo-
Algorithmus. Die konkrete Realisierung ist unter Unterabschnitt 4.2.3 detaillierter
ausgeführt.
Trotz der bekannten Nachteile von GUID und datenbankgenerierten Primärschlüsseln
wird der Sequence-Mechanismus vom Entity Framework nicht
unmittelbar unterstützt. Die eigene, wiederverwendbare Implementierung,
besteht nur aus wenigen Zeilen Quellcode, aber gerade dieser Umstand ließe
erwarten, dass diese Variante als fixer Bestandteil eines Frameworks bereitgestellt
wird. Auch wenn die eigene Implementierung nur aus wenigen Zeilen
besteht, waren doch fortgeschrittene Kenntnisse für die Implementierung erforderlich.
Konkrete Hinweise dazu fanden sich in der Dokumentation nicht.
Die Situation bei Genome entspricht weitgehend der beim Entity Framework.
Wird Oracle als Datenbank verwendet, steht als zusätzliche Variante
Sequence zur Verfügung. Da die Beispielanwendung auch mit dem Microsoft
SQL-Server zusammenarbeiten soll, wurde wie beim Entity Framework
eine eigene Lösung zum Nachbilden des Sequence-Mechanismus erstellt. Die
Umsetzung war mit noch etwas weniger Quellcode zu realisieren und mit
Grundkenntnissen in ca. fünf Stunden zu schaffen. Trotzdem wäre auch hier
eine integrierte Lösung wünschenswert.
3.2.3 Beziehungen
Grundsätzlich können mit allen drei Produkten alle in Unterabschnitt 2.2.2
beschriebenen Beziehungen definiert werden. Beim Entity Framework sind
alle Beziehungen automatisch bidirektional. Unidirektionale Beziehungen
werden nicht unterstützt. Genome und NHibernate bieten nur unidirektionale
Beziehungen, bidirektionale Beziehungen werden aus zwei unidirektionalen
Beziehungen aufgebaut.
Ob beim Löschen eines Datensatzes, der Detaildatensätze enthält, das
Löschen verhindert werden soll oder ob in diesem Fall auch die Detaildatensätze
automatisch gelöscht werden sollen, kann bei NHibernate und beim
Entity Framework in den Metadaten definiert werden. Bei Genome ist dafür

3. Evaluierung 29
eine Ereignismethode in der Entitätsklasse zu implementieren, die das Löschen
gegebenenfalls verhindert bzw. vorhandene Detaildatensätze explizit
löscht. Listing 3.9 zeigt eine entsprechende Implementierung aus der Klasse
PurchOrder. Die Klasse muss das Interface IDeleteCallback implementieren.
Listing 3.9: Genome: Bestellpositionen automatisch mit der Bestellung löschen.
1 #region IDeleteCallback Members
2
3 public void OnDelete()
4 {
5 foreach (PurchOrderLine ol in OrderLines)
6 Context.GetEffectiveContext(this).Delete(ol);
7 }
8
9 #endregion
Für den Zugriff auf in Beziehung stehende Datensätze über entsprechende
Datenkomponenten der Enitätsklassen gibt es verschiedene Strategien.
Entweder müssen die Daten explizit vor dem ersten Zugriff aus der Datenbank
geladen werden, wie es beim Entity Framework der Fall ist, oder
sie werden beim ersten Zugriff automatisch nachgeladen (Laden bei Bedarf,
siehe Unterabschnitt 2.2.7). Die zweite Variante kommt bei Genome zum
Einsatz. Eine weitere mögliche Variante ist, referenzierte Daten sofort mitzuladen,
entweder in einer Join-Abfrage oder in zwei aufeinander folgenden
Befehlen, auch gieriges Laden (Greedy Loading) genannt. Nur bei NHibernate
kann jede dieser Varianten, für jede Beziehung individuell, in den Metadaten
definiert werden. Alle drei Produkte bieten noch die Möglichkeit,
in einer Abfrage festzulegen, welche Beziehungen automatisch sofort mitgeladen
werden sollen. Die entsprechenden Anweisungen heißen bei Genome
PreCache, bei Entity Framework Include und bei NHibernate Fetch bzw.
SetFetchMode. Bei Genome können die in Beziehung stehenden Datensätze,
die nachgeladen werden sollen, über einfache oder komplexe Kriterien zusätzlich
eingeschränkt werden. Für Laden bei Bedarf müssen bei NHibernate
und Genome die mit den Produkten gelieferten Behälterklassen verwendet
werden.
Microsoft unterscheidet bei Laden bei Bedarf zwischen implizitem und
explizitem Laden bei Bedarf [16]. Das Entity Framework unterstützt nur
explizites Laden bei Bedarf. Vor dem ersten Zugriff muss die Methode Load
aufgerufen werden. Beim impliziten Laden bei Bedarf, wie es NHibernate
und Genome unterstützen, wird dieser Aufruf bei Bedarf automatisch
ausgeführt. Das Entity Framework unterstützt implizites Laden bei Bedarf
nicht, was auch häufig kritisiert wird [64]. Mitglieder des Entity Framework-
Entwicklungsteams stellen in Aussicht, implizites Laden bei Bedarf in einer
späteren Version zu implementieren [14, 17].

3. Evaluierung 30
3.2.4 Eingebetteter Wert
Diese in Unterabschnitt 2.2.3 beschriebene Möglichkeit, Klassen auf Tabellen
abzubilden, wird nur von NHibernate ausreichend unterstützt. Bei Genome
sowie beim Entity Framework wird dieser Mechanismus grundsätzlich angeboten,
jedoch mit der Einschränkung, dass diese eingebetteten Klassen
keine Beziehungen zu weiteren Entitäten beinhalten dürfen. Schon einfache
Beispiele, die in diesem Zusammenhang genannt werden, wie Geldbeträge
[FRF02, S. 268] oder Adressen, können damit nicht richtig abgebildet
werden. Bei einem Geldbetrag wird eine Beziehung zur Währung, bei
Adresse zumindest eine Beziehung zu Land benötigt. Umgangen kann diese
Einschränkung bei Genome und dem Entity Framework werden, indem nur
die Abbildung der Fremdschlüssel-Attribute (z. B. CurrencyId bzw. CountryId)
ohne die zugehörigen Beziehungen definiert werden. Definiert wird
eingebetteter Wert in NHibernate mit dem XML-Element Component, beim
Entity Framework mit ComplexType. EmbeddedStruct ist das entsprechende
XML-Element bei Genome, obwohl damit auch Klassen eingebettet werden
können.
3.2.5 Vererbung
Von allen Testkandidaten werden alle drei möglichen Vererbungs-Varianten
(siehe Unterabschnitt 2.2.4) unterstützt. Genome benötigt, im Gegensatz
zum Entity Framework und zu NHibernate, auch bei Vererbung mit einer
Tabelle pro Klasse ein Diskriminator-Attribut.
Über das grafische Designer-Werkzeug des Entity Framework kann nur
die Variante „Vererbungshierarchie in einer Tabelle“ definiert werden. Die
beiden alternativen Varianten können, durch manuelles Anpassen des XML-
Quelltextes in der edmx-Datei, definiert werden, wobei das manuelle Bearbeiten
besonders erschwert wird, da die einzelnen XML-Elemente, die eine
Vererbung definieren, über das gesamte Entity Data Model verteilt sind und
Vererbung nicht explizit über entpsrechende Elemente ausgedrückt wird. Die
Vergleichsprodukte weisen zumindest „Vererbungshierarchie in einer Tabelle“
und „Vererbung mit einer Tabelle pro Klasse“ durch spezielle XML-
Elementen aus. Bei NHibernate sind dies subclass und joined-subclass, bei
Genome SharedInheritance und JoinedInheritance.
3.2.6 Nebenläufigkeit
Das ADO.NET Entity Framework unterstützt nur optimistische verbindungslose
Sperren (Optimistic Offline Lock) [24]. NHibernate und Genome
bieten dagegen auch pessimistitsche Sperren (Pessimistic Lock), also Sperren,
die auf Datenbankebene gesetzt werden (siehe Unterabschnitt 2.2.6).
Alle drei Produkte können bei optimistischer verbindungsloser Sperre
eine beliebige Auswahl an Attributen einer Tabelle zur Konflikterkennung

3. Evaluierung 31
heranziehen. Die effizienteste Lösung besteht allerdings darin, nur ein Attribut
als Datensatzversion zu verwenden. Der Microsoft SQL-Server bietet
speziell für diesen Zweck den Datentyp Timestamp. Um die Portabilität
nicht unnötig einzuschränken, wurde für die Beispielanwendung jedoch ein
Ganzzahliges Versionsattribut verwendet.
NHibernate bietet hier die einfachste Lösung. Es genügt, in der Konfiguratonsdatei
eine Property der Klasse für die Konflikterkennung zu Kennzeichnen.
NHibernate erkennt am Datentyp automatisch, ob es den Wert
beim Speichern von Änderungen erhöhen muss, oder ob das Attribut von
der Datenbank aktualisiert wird.
Wird der Datentyp Timestamp für das Versionsattribut verwendet, ist
auch beim ADO.NET Entity Framework die Konfiguration ähnlich unkompliziert.
Soll der Datentyp Ganzzahl verwendet werden, ist der Entwickler
für das Erhöhen des Wertes beim Speichern zuständig. Die Implementierung
ist, wie beim Sequence-Mechanismus, mit wenigen Zeilen Quellcode zu
realisieren, aber für Einsteiger nicht unbendingt naheliegend (siehe Unterabschnitt
4.2.6).
Genome akzeptiert bei Verwendung des Microsoft SQL-Server nur den
Datentyp Timestamp für das Versionsattribut, obwohl in Zusammenarbeit
mit Oracle der Datentyp Ganzzahl dafür unterstützt wird. Die Portabilität
wird dadurch unnötig eingeschränkt. Im Supportforum wurde auf Anfrage
ein Lösungsansatz geschildert, wie auch mit dem SQL-Server der Ganzzahl-
Datentyp für das Versionsattribut verwendet werden kann, der aber zu komplex
erschien, um ihn im Zuge dieser Arbeit umzusetzen. Für die Genome-
Beispielapplikation wurde deshalb der Datentyp Timestamp verwendet, wodurch
eine eigenes, entsprechend abweichendes Datenbankschema erstellt
werden musste. Weiters muss bei Genome jede Sperre für jedes Objekt explizit
gesetzt werden.
3.2.7 Abfragen
OQL
Alle drei Testkandidaten bieten mehrere Möglichkeiten, Abfragen gegen das
konzeptionelle Modell abzusetzen. Eine an OQL angelehnte Abfragesprache,
die als Zeichenkette übergeben wird, wie in Unterabschnitt 2.2.10 beschrieben,
bieten alle untersuchten Produkten. Bei NHibernate wird sie HQL (Hibernate
Query Languag), bei Genome OQL (Object Query Language) und
beim Entity Framework eSQL bzw. Entity-SQL bezeichnet.
LINQ
Das ADO.NET Entity Framework bietet schon seit den ersten Testversionen
LINQ-Unterstützung. Für Genome ist diese Abfragevariante seit einigen

3. Evaluierung 32
Monaten verfügbar und dürfte bereits stabil sein. NHibernate hinkt den beiden
anderen Testkandidaten diesbezüglich noch deutlich hinterher. Für die
im August veröffentlichte Version 2.0 wurde die LINQ-Unterstützung nicht
rechtzeitig fertig. Über einen möglichen Zeitpunkt der Fertigstellung wurde
noch nichts bekannt gegeben.
SQL
NHibernate und Genome bietet noch zusätzlich die Möglichkeit, SQL als
Abfragesprache zu nutzen. Da mit diesem Mechanismus die Abstraktion
der Datenbank aufgeweicht wird, sollte genau abgewogen werden, ob ein
konkreter Anwendungsfall diese Einschränkung rechtfertigt.
3.3 Softwarearchitektur
3.3.1 Unabhängigkeit der Entitätsklassen von der Persistenzschicht
(Persistence Ignorance)
Jede O/R-Mapping-Lösungen schränkt die Freiheit beim Entwurf der Entitätsklassen
in gewissem Masse ein. So setzen alle Produkte eine ID-Property
in den Entitätsklassen voraus, um die Objekte im Speicher eindeutig den
persistierten Datensätzen zuordnen zu können.
Bei Genome müssen die Entitätsklassen abstrakte Klassen sein. Genome
generiert zur Übersetzungszeit automatisch Quelltext für die dazugehörige
konkrete Implementierung. Die Objekterzeugung muss deshalb an das
Framework delegiert werden. Ein Vorteil dieser Vorgangsweise ist, dass Methoden
zum Hinzufügen und Entfernen von Detaildatensätzen automatisch
generiert werden. Ein Konstruktor, der alle in den Metadaten dieser Entität
definierten Properties als Parameter akzeptiert, muss aber für jede
Klasse manuell implementiert werden. Es wird empfohlen, Entitätsklassen
von TechTalk.Genome.Persistent abzuleiten, da darin die Vergleichsoperatoren
überschrieben sind und einige weitere Methoden bereitgestellt werden,
die den Umgang mit den Entitätsklassen erleichtern. Zum Abbilden
von Beziehungen müssen die vom Framework bereitgestellten Behälterklassen
verwendet werden. Für alle Datenkomponenten, die persistiert werden
sollen, müssen Properties definiert werden, die abstrakt und entweder geschützt
oder öffentlich sind. Properties, die dem Entwickler nur lesenden
Zugriff ermöglichen oder die zusätzliche Programmlogik enthalten sollen,
müssen doppelt implementiert werden. Einmal als abstrakt und geschützt,
damit sie nur dem Persistierungsframework zugänglich sind, und ein zweites
Mal unter anderem Namen und öffentlich mit der gewünschten zusätzlichen
Programmlogik, die den Zugriff auf die erste Property weiterleitet. Das Implementieren
der Schnittstelle IDeleteCallback wird zusätzlich erforderlich,

3. Evaluierung 33
wenn beim Löschen eines Datensatzes die Detaildatensätze automatisch mitgelöscht
werden sollen.
NHibernate benötigt neben der ID-Property noch einen parameterlosen
Konstruktor in den Entitätsklassen. Behälterklassen für Beziehungen dürfen
nur mit Schnittstellen, nicht jedoch mit konkreten Implementierungen
definiert werden. Soll Laden bei Bedarf zum Einsatz kommen, müssen außerdem
alle Methoden und Properties virtuell sein, damit NHibernate die
in diesem Fall benötigten Proxies erzeugen kann. Datenkomponenten kann
NHibernate entweder direkt oder über zugehörige Properties persistieren,
auch wenn der Lese- oder Schreibzugriff privat oder geschützt ist.
Beim ADO.NET Entity Framework werden die Entitätsklassen normalerweise
aus dem konzeptionellen Modell generiert. Die resultierenden Klassen
sind von System.Data.Objects.DataClasses.EntityObject abgeleitet, das
selbst von StrukturalObject ableitet und die Schnittstellen IEntityWithKey,
IEntityWithChangeTracker sowie IEntityWithRelationships implementiert.
StrukturalObject implementiert die Schnittstellen INotifyPropertyChanging
sowie INotifyPropertyChanged. Da das Entity Framework und somit alle enthaltenen
Klassen und Schnittstellen Teil des .NET-Framework sind, wird
dadurch keine Abhängigkeit zu zusätzlichen Frameworks verursacht. Von
der Idealvorstellung eines POCO sind diese Entitätsklassen trotzdem weit
entfernt.
Der generierte Quelltext wird bei jeder Änderung der Metadaten neu generiert.
Die Entitätsklassen sind deshalb als partielle Klassen definiert und
können somit manuell erweitert werden, ohne dass diese Änderungen von
der automatischen Quelltextgenerierung überschrieben werden. Bei diesen
manuellen Erweiterungen ist jedoch immer auf die vorhandene Programmlogik
Rücksicht zu nehmen [19]. Die gebotenen Möglichkeiten sind dadurch
erheblich eingeschränkt. Das Entity Framework kann auch manuell erstellte
Entitätsklassen persistieren. Bei solchen Klassen wird vorausgesetzt, dass
sie die Schnittstellen IEntityWithKey, IEntityWithChangeTracker und IEntityWithRelationships
implementieren, wenn zugehörige Funktionalität wie
ein Id-Property, integrierte Änderungsüberwachung oder eine Beziehung benötigt
wird. Weitere Informationen dazu finden sich in [22].
Schon seit längerer Zeit stellen sich einzelne Mitglieder des Entwicklungsteams
der Diskussion mit Anwendern, die eine weitere Annäherung an
vollständige Unabhängigkeit der Entitätsklassen von der Persistenzschicht
für die nächste Version des Entity Framework erwarten [49, 51].
Wie schon in Unterabschnitt 3.2.3 ausgeführt wurde, unterstützt das
Entity Framework nur bidirektionale Beziehungen, wodurch die eventuell
gewünschte Kapselung aufgweicht wird, die die öffentliche Schnittstelle einer
Klasse unnötig erweitert wird.

3. Evaluierung 34
3.3.2 Unterstützte Datenbanksysteme
Beim ADO.NET Entity Framework wird über ein Providermodell die Unterstützung
unterschiedlicher RDBMS ermöglicht. Microsoft liefert nur Provider
für die eigenen Datenbankprodukte. An der Unterstützung weiterer
RDBMS wird von anderen Anbietern bereits gearbeitet [57]. Die Firma Devart
bietet Provider für die Unterstützung von Oracle, MySQL, PostgreSQL
und SQLite [7, 36, 38, 53, 54]. Unter [47, 63] wird ein SQLite-Provider zum
Download angeboten. Provider für eine Reihe weiterer RDBMS sind angekündigt
[57]. Sybase iAnywhere stellt mittlerweile auch einen Provider für
das Entity Framework zur Verfügung [48].
Von den untersuchten Produkten unterstützt NHibernate zurzeit noch
die größte Anzahl an Datenbanksystemen, wobei das Entity Framework bereits
aufholt. Neben Microsoft SQL-Server, Oracle 9i und Oracle 10g, arbeitet
NHibernate mit einer Reihe weiterer kommerzieller und freier RDBMS
zusammen [40].
Genome unterstützt grundsätzlich nur den SQL-Server von Microsoft
sowie dessen CE-Variante, Oracle 9i und 10g sowie IBM DB2, wobei diese
Auswahl bei der Express-Edition weiter eingeschränkt ist.
3.4 Produktivität
3.4.1 Codegenerierung
Enitätsklassen aus Metadaten generieren
Das ADO.NET Entity Framework generiert die Entitätsklassen automatisch
entsprechend des konzeptionellen Schemas in den Metadaten. Änderungen
direkt in den Metadaten oder über das grafische Designer-Werkzeug initiieren
beim Speichern die erneute Generierung der Quelltextes. Mit NHibernate
wird seit der Version 1.2 das Kommandozeilenwerkzeug hbm2net mitgeliefert,
das auch aus den Metadaten den Quelltext für die Entitätsklassen
generieren kann. Genome wird ohne vergleichbare Funktionalität geliefert.
Datenbank-Schema aus Metadaten generieren (Forward Engineering)
Genome enthält einen in Visual Studio integrierten Assistenten, der das Datenbankschema
entsprechend den Metadaten aktualisiert. NHibernate bietet
in der Laufzeitumgebung eine entsprechende Funktionalität, die per Konfigurationseinstellung
oder über einen Aufruf der entsprechenden Funktion
das Datenbankschema aus den Metadaten neu erzeugt. Beim ADO.NET
Entity Framework fehlt eine enstprechende Funktionalität.

3. Evaluierung 35
Abbildung 3.2: Assistent von Genome zum Erstellen der Metadaten aus
einer Entitätsklasse.
Metadaten aus den Entitätsklassen generieren
Genome kann aus dem Quelltext der Entitätsklassen die Metadaten erzeugen.
Dazu wird im Kontextmenü des Quelltexteditors ein zusätzliches
Untermenü „Genome Mapping“ eingeblendet, das eine Reihe verschiedener
Abbildungsmöglichkeiten zur Auswahl anbietet (siehe Abbildung 3.2).
NHibernate kann die Metadaten zwar nicht aus dem Quelltext der Entitätsklassen
generieren, bietet jedoch die Möglichkeit, die Metadaten als Attribute
in den Quelltext zu integrieren. Die von NHibernate zur Laufzeit
benötigten Metadaten im XML-Format kann es automatisch aus diesen generieren.
Das Entity Framework bietet keine vergleichbare Funktionalität.
Entitätsklassen und Metdaten aus dem Datenbankschema generieren
(Reverse Engineering)
Das Entity Framework sowie Genome bieten in Visual Studio integrierte
Assistenten, die aus einer Datenbank, die über die Verbindungsparameter
festgelegt wird, die Metadaten und die Entitätsklassen automatisch gene-

3. Evaluierung 36
rieren. Dabei wird davon ausgegangen, dass das konzeptionelle Modell dem
Datenbankschema direkt entspricht. Bei den Assistenten beider Produkte
können Tabellen und Views ausgewählt werden, welche verarbeitet werden
sollen. Beziehungen in der Datenbank werden generell als normale Beziehung
importiert, auch wenn diese als Vererbung gedacht waren. Die richtige
Beziehungsvariante automatisch zu erkennen ist kaum möglich, da sich
die Varianten im Datenbankschema nicht eindeutig unterscheiden lassen.
Die falsch erzeugten Beziehungen zwischen Entitätsklassen und die entsprechenden
Metadaten müssen nachträglich manuell korrigiert werden. Wünschenswert
wäre es daher, über einen Dialog die richtige Variante vor dem
Generieren auswählen zu können.
Beide Produkte können, neben der initialen Erzeugung der Metadaten
und der Entitätsklassen, auch nachträgliche Änderungen übernehmen. Das
Entity Framework sollte dabei das Speichermodell aktualisieren, sowie neu
hinzugekommene Elemente dem konzeptionellen Schema und der Abbildungsdefinition
hinzufügen, aber manuelle Anpassungen im konzeptionellen
Modell unberührt lassen. Leider funktioniert das nicht zuverlässig [4, 10].
So müssen teilweise Änderungen im konzeptionellen Modell, nach jeder Aktualisierung
aus dem Datenbankmodell, wieder manuell berichtigt werden.
Während dieser Arbeit wurde diese Vorgehensweise in Genome nicht näher
untersucht, da es durchwegs einfacher erschien, alle Änderungen in den Entitätsklassen
manuell durchzuführen und daraus über den Assistenten die
Metadaten aktualisieren zu lassen.
NHibernate wird ohne vergleichbare Funktionalität geliefert. Wie bei
Genome sind der Quellcode der Entitätsklassen und die Metadaten so übersichtlich,
dass sie für ein Projekt in der Größenordnung der Beispielapplikation
und auch darüber hinaus, ohne weiteres manuell erstellt und gewartet
werden können. Es sind jedoch von Drittanbietern entsprechende Werkzeuge
verfügbar [39, 42].
3.4.2 Designer-Werkzeug
Wie bei Microsoft-Produkten üblich, wird auch das Entity Framework mit
einem grafischen Designer-Werkzeug geliefert, das den Entwickler in diesem
Fall von der mühsamen und komplizierten manuellen Bearbeitung der XML-
Metadaten befreien soll. Abbildung 3.3 zeigt einige grundlegende Elemente
des grafischen Designer-Werkzeugs. Der linke obere Bereich in dieser Abbildung
zeigt den Entwurfsbereich für das konzeptionelle Modell. Damit können
neue Entitätsklassen eingefügt werden, bestehende geändert oder gelöscht
werden. Weiters können Beziehungen zwischen den Klassen erstellt und bearbeitet
werden. Der „Model Browser“, nimmt in der Abbildung den rechten
oberen Bereich ein. Damit kann im gesamten Entity Data Model navigiert
werden. Die Abbildungsdefinition kann über das „Mapping Details“-Fenster
bearbeitet werden, das in der Abbildung links unten gezeigt wird. Über das

3. Evaluierung 37
Abbildung 3.3: Grafisches Designer-Werkzeug des Microsoft ADO.NET
Entity Framework.
im rechten unteren Bereich dargestellten Eigenschaftsfenster können weitere
Eigenschaften des jeweils in einem der anderen Bereiche ausgewählten
Elements, angezeigt und teilweise bearbeitet werden.
Zurzeit bietet das Designer-Werkzeug für wesentliche Konstrukte noch

3. Evaluierung 38
keine Unterstützung, wie z. B. Vererbung mit einer Klasse pro Tabelle, Vererbung
mit einer Klasse pro konkreter Tabelle oder eingebetteter Wert.
Die manuelle Bearbeitung der Metadaten ist daher oft unerlässlich. Werden
Elemente wie z. B. ComplexType für eingebettete Werte, die das Designer-
Werkzeug nicht unterstützt, manuell eingefügt, lässt sich diese Datei nicht
mehr mit dem Designer-Werkzeug öffnen. Weiters ist nicht vorgesehen, das
Speichermodell im Designer-Werkzeug zu bearbeiten, es kann aber über
„Update Model from Database“ aus einem vorhandenen Datenbankschema
generiert werden. Dabei werden auch das konzeptionelle Modell und die
Abbildungsdefinition generiert, bzw. bei Vorhandensein aktualisiert, wobei
manuell vorgenommene Änderungen teilweise überschrieben oder verworfen
werden.
NHibernate und Genome werden ohne grafisches Designer-Werkzeug geliefert.
3.4.3 Visual Studio Integration
Alle Assistenten und das grafische Designer-Werkzeug des Entity Framework
sind Teil von Visual Studio Service Pack 1 und sind entsprechend vollständig
integriert. Genome liefert zwar keinen grafisches Designer-Werkzeug,
aber eine Reihe von Assistenten, die durchwegs innerhalb von Visual Studio
über Kontextmenüs an den relevanten Stellen aufgerufen werden können
sowie Visual Studio-Projektvorlagen für verschiedene Anwendungsfälle. Die
von NHibernate gebotene Visual Studio-Integration fällt dagegen etwas minimalistisch
aus. Mitgelieferte XML-Schema-Dateien aktivieren Intellisense
beim Bearbeiten der XML-Metadatendateien. Diese Dateien sind manuell in
das Visual Studio-Installationsverzeichnis zu kopieren [KBK08, S. 40] [12].

Kapitel 4
Implementierung
Der Quelltext der Beispielanwendung befindet sich auf der beiliegenden CD
im Anhang.
4.1 Anforderungen
Die erstellte Beispielapplikation soll wesentliche Elemente beinhalten, die in
typischen Geschäftsapplikationen Verwendung finden, deren Daten in relationalen
Datenbanksystemen persistiert werden. Dazu zählen jedenfalls 1:n-
Beziehungen wie sie in relationalen Datenbanksystemen üblich sind. Weiters
soll gezeigt werden, welche der beim objektorientierten Entwurf üblichen
Konstrukte mit Standardprodukten in RDBMS persistierbar sind.
Dazu zählt zumindest die Vererbung sowie m:n-Beziehungen. Objektmodelle
sind üblicherweise feingranularer als relationale Modelle (siehe Unterabschnitt
2.2.3). Ob diese trotzdem persistiert werden können, ist ein weiterer
untersuchter Punkt. Die Idealvorstellung ist, dass die Persistierung der Objekte
in ein RDBMS transparent passieren soll und dem Entwickler beim
objektorientierten Entwurf keine Einschränkungen auferlegt werden sollen,
nur um diese Persistierung zu ermöglichen (siehe Unterabschnitt 2.2.8). Entsprechend
unkompliziert soll auch das Wiederherstellen persistierter Objekte
ablaufen (siehe Unterabschnitt 2.2.7).
Der Schwerpunkt der Beispielanwendung liegt jedenfalls beim objektorientierten
Entwurf. Das Abbilden gewachsener Datenbankschemata auf
Objekte bleibt unberücksichtigt. Deshalb wurden beispielsweise nur künstliche
Schlüssel verwendet. Die Unterstützung natürlicher Schlüssel oder gar
zusammengesetzter natürlichen Schlüssel durch das Persistenz-Framework
wurden dagegen nicht untersucht. Die Beispielapplikation soll möglichst
ohne Änderungen mit allen unterstützten Datenbanken funktionieren. Dieser
Aspekt wurde zwar nicht konkret untersucht, soweit möglich wurde jedoch
darauf verzichtet, Funktionalität zu verwenden, die nur von einzelnen
RDBMS geboten wird, wie z. B. der Identity-Datentyp des Microsoft SQL-
39

4. Implementierung 40
Server.
Mit jedem Produkte soll gezeigt werden, wie weit diese Anforderungen
erfüllt werden können bzw. wo Abstriche notwendig sind. Es war vorgesehen,
ein einheitliches Datenbankschema für alle drei Implementierungen zu
verwenden. Für Genome musste jedoch von diesem gemeinsamen Datenbankschema
abgewichen werden (siehe Unterabschnitt 3.2.5 und Unterabschnitt
3.2.6).
4.2 Realisierung
Mit allen drei Produkten wurde eine Clientapplikation entwickelt, die alle
Datensätze löscht und die Tabellen neu mit Daten befüllt. Weiters kam
auch das Wiederherstellen der Objekte aus den Datensätzen der Datenbank
zum Einsatz. Getestet wurde die Applikation mit dem Microsoft SQL-Server
2005 Express Edition. Abbildung 4.1 zeigt das Klassendiagramm der Beispielanwendung
und Abbildung 4.2 das entsprechende Datenbankschema, in
das die Objekte persistiert werden.
4.2.1 Visual Studio Projektorganisation
Die verschiedenen Projekte für die drei Implementierungen, wurden zu einer
gemeinsamen Visual Studio-Solution zusammengefasst. Für NHibernate
wurden die Entitätsklassen im Projekt DAL_NHibernate, die Metadaten
im Unterordner HBM erstellt. Im Projekt Client_NHibernate befindet sich
die Clientapplikation. Das Entity Data Model des ADO.NET Entity Framework
befindet sich im Projekt DAL_EF. Die manuell erstellten Erweiterungen
zu den generierten Entitätsklassen im Unterordner ERPEntities.
Für die zugehörige Clientapplikation wurde das Projekt Client_EF erstellt.
Die Aufteilung für Genome weicht etwas von den anderen beiden Lösungen
ab. Genome verlangt ein eigenes Projekt für die Metadaten, dafür wurden
der Projektname DAL_Genome verwendet. Die Entitätsklassen befinden
sich in Business_Genome, die Clientapplikation wieder erwartungsgemäß
in Client_Genome. Um eine bestimmte Lösung aus Visual Studio heraus
auszuführen, ist es notwendig vorher die entsprechende Clientapplikation
als Startprojekt festzulegen.
4.2.2 Vererbung
Alle drei in Unterabschnitt 2.2.4 beschriebenen Varianten der Vererbung,
wurden in der Beispielapplikation umgesetzt. Die Klasse Contacts und die
davon abgeleiteten Klassen Customer und Vendor, werden mit Vererbung
mit einer Tabelle pro Klasse auf die entsprechenden Tabellen Contact, Customer
und Vendor abgebildet. Die Klassen SalesOrder und PurchOrder mit

4. Implementierung 41
Abbildung 4.1: Das Klassendiagramm der NHibernate-Implementierung.
der Basisklasse Order, sowie die Klassen SalesOrderLine und PurchOrderLine
mit der Basisklasse OrderLine, werden mit Vererbung mit einer Tabelle
pro konkreter Klasse auf die Tabellen SalesOrder, SalesOrderLine, PurchOrder
und PurchOrderLine abgebildet. Die dritte Variante, Vererbungshierarchie
in einer Tabelle, kommt bei den Klassen Article und Service mit der
gemeinsamen Basisklasse Item zum Einsatz. Im Genome-spezifischen Datenbankschema
wurde in der Tabelle Contact zusätzlich das von Genome
benötigte Diskriminator-Attribut ContactType eingefügt.

4. Implementierung 42
Country
Id
ISOCode
Name
Version
AlternativeAddress
Id
StreetAddress
City
ZipCode
CountryId
ContactId
Version
SalesOrderLine
Id
SalesOrderId
ItemCount
ItemPrice
TaxCode
ItemId
Version
RowId
Id
NextValue
Version
Customer
Id
SalesOrder
Id
PaymentDueDate
CustomerId
Version
OrderDate
Contact
Id
FirstName
LastName
StreetAddress
City
ZipCode
CountryId
Version
Item
Id
ItemNumber
ItemName
Price
StockCount
ItemType
Version
Vendor
Id
PurchOrder
Id
VendorId
Version
OrderDate
DiscountPercent
PurchOrderLine
Id
VendorItem
PurchOrderId
ItemCount
ItemPrice
TaxCode
ItemId
Version
VendorId
Abbildung 4.2: Das Datenbankschema der Entity Framework- und
NHibernate-Implementierung.
4.2.3 ID-Generierung
Alle Produkte im Vergleich untertützen verschiedene Möglichkeiten, Werte
für die künstlichen Schlüssel zu generieren und zuzuweisen. Die für die Beispielapplikation
gewählte Variante sollte vor allem mit jedem RDBMS ohne
weitere Anpassung funktionieren und trotzdem effizient sein. Am effizientesten
ist der Sequence-Mechanismus (siehe Unterabschnitt 2.2.1). Leider wird
dieser nicht von allen RDBMS unterstützt. Aus diesem Grund wurde die
Variante gewählt, die den Sequence-Mechanismus nachbildet. Dafür wurde
ItemId

4. Implementierung 43
eine zusätzliche Tabelle RowId wurde eingeführt mit einem Attribut Next-
Value, in dem der nächste verfügbare Wert abgelegt wird. Die Attribute Id
und Version sind für die Verwendung durch das O/R-Mapping-Framwork
notwendig.
NHibernate unterstützt diese Variante direkt. Es genügte somit die Metadaten
entsprechend zu ergänzen. Das ADO.NET Entity Framework und
Genome hingegen bieten keine entsprechende Unterstützung. Es war deshalb
notwendig, eine eigene Lösung für das Abholen neuer Werte, sowie das
Zuweisen an neu erzeugte Objekte zu implementieren.
Der Zugriff auf die Tabelle RowId wurde, wie auch bei den anderen Tabellen
an das jeweilige O/R-Mapping-Framework delegiert. Jedoch musste
dazu eine eigene Arbeitseinheit erzeugt werden, da dieser Zugriff nicht in
der selben Transaktion durchgeführt werden darf wie die restlichen Datenbankzugriffe.
In der zugehörigen Enitätsklasse wurde eine Klassenmethode
NextId implementiert, die eine gewisse Anzahl an IDs in der Tabelle reserviert
und diese reservierten Werte nach und nach an Aufrufer der Methode
abgibt, bis diese aufgebraucht sind um dann wieder mehrere Werte auf ein
Mal zu reservieren. Damit gleichzeitige Versuche mehrere Clients, neue IDs
zu reservieren wird durch optimistische verbindungslose Sperre erkannt. Im
Kollisionsfall wird die Reservierung wiederholt. Stored Procedures oder angepasste
SQL-Befehle, die das Attribut NextValue erhöhen wären für diesen
Zweck effizienter. Der Zweck dieser Lösung war jedoch, die grundsätzliche
Machbarkeit zu prüfen ohne den Anspruch auf die effizienteste Implementierung
zu stellen. Eine weitere Herausforderung war das Zuweisen der ID-
Werte an neue Entitäten. Der Konstruktor eignet sich dazu nicht, da dieser
auch aufgerufen wird, wenn ein Objekt aus der Datenbank wiederhergestellt
wird.
Beim Entity Framework schien das Ereignis SavingChanges der Arbeitseinheit
(ObjectContext) der beste Zeitpunkt für die Zuweisung der neuen
ID-Werte zu sein. Zu diesem Zeitpunkt können die betreffenden Objekte
bereits unterschieden werden und es ist noch rechtzeitig vor dem Schreiben
der Werte in die Datenbank. Die Arbeitseinheit bietet Zugriff auf den ObjectStateManager,
über den alle in dieser Arbeitseinheit neu hinzugefügten
Entitäten abgefragt werden können. Die Entitätsklassen müssen die Schnittstelle
IEntity und somit die Methode SetId implementieren, über die die
Werte zugewiesen werden.
Für Genome wurde das Anfordern neuer ID-Werte auf die gleiche Weise
realisiert, wie für das Entity Framework. Das Zuweisen der Werte ließ sich
dagegen wesentlich einfacher realisieren. Ein von einer Fabrikmethode des
Frameworks benötigter Konstruktor wird nur dann aufgerufen, wenn neue
Objekte erzeugt werden. Daher kann zu diesem Zeitpunkt ein neuer ID-Wert
einfach zugewiesen werden. Es ist jedoch notwendig, diese Zuweisung in jede
Entitätsklasse zu einzubauen.

4. Implementierung 44
4.2.4 Beziehungen
Es wurden einige 1:n-Beziehungen definiert, wie z. B. zwischen Contact und
AlternativeAddress oder zwischen PurchOrder und Vendor bzw. SalesOrder
und Customer. Wobei im ersten Fall die linke Seite der Beziehung eine
abstrakte Basisklasse ist, die diese Beziehung an die abgeleiteten Entitäten
vererbt, bei den letzten Beiden Fällen wurde die Beziehung in den abgeleiteten
Klassen definiert. Bei der Beziehungen zwischen OrderLine und
Item, werden beide Seiten der Beziehung von den abstrakten Basisklassen,
an die abgeleiteten Klassen vererbt. Die Klasse Address sollte als eingebetteter
Wert abgebildet werden und die 1:n-Beziehung zu Country sollte
deshalb eine Beziehung von einem eingebetteten Wert zu einer weiteren Entität
darstellen. Da das Entity Framework und Genome solche Beziehungen
nicht unterstützen, wurde diese Variante nur mit NHibernate realisiert (siehe
Unterabschnitt 4.2.5). Eine n:m-Beziehung wurde zwischen den Entitäten
Vendor und Article realisiert, die widergeben soll, welche Artikel von welchem
Lieferanten bestellt werden können.
4.2.5 Feingranulares Objektmodell
Die Klasse Address sollte als ein Attribut der Entitäten Contact sowie AlternativeAddress
realisiert werden, wie im Unterabschnitt 2.2.3 als eingebetter
Wert beschrieben. Das Entity Framework und Genome können Beziehung
zwischen eingebetten Objekten und weiteren Entitäten nicht abbilden, deshalb
wurden die Addressattribute direkt in die Entitäten Contact sowie AlternativeAddress
eingefügt. Nur mit NHibernate konnte diese Konstruktion
wie vorgesehen umgesetzt werden.
4.2.6 Nebenläufigkeit
Zur Erkennung von Konflikten bei gleichzeitigen Änderungen durch mehrere
Geschäftstransaktionen wurde optimistische verbindungslose Sperre mit
einem eigens dafür erstelltem Attribut „Version“ vom Datentyp Ganzzahl
verwendet. Genome unterstützt mit dem Microsoft SQL-Server für diesen
Zweck nur den Datentyp Timestamp. Das war einer der in Abschnitt 4.1 angeführten
Gründe, warum für Genome ein abweichendes Datenbankschema
erstellt wurde.
Auch das Entity Framework bietet für ein Versionsfeld vom Datentyp
Ganzzahl nur unvollständige Unterstützung. Ein entsprechendes Attribut
vom Datentyp Timestamp, wird vom Microsoft SQL-Server bei jeder Änderung
des Datensatzes automatisch aktualisiert. Bei Ganzzahl muss diese
Aktualisierung vom O/R-Mapping-Framework selbst vorgenommen werden.
Im Entity Framework ist das jedoch nicht vorgesehen, weshalb dafür weitere
Anpassungen notwendig sind. Wie beim Zuweisen neuer ID-Werte, war
das Ereignis SavingChanges der Arbeitseinheit auch hier zielführend. Der

4. Implementierung 45
ObjectStateManager liefert alle Enitäten, die in der aktuellen Arbeitseinheit
geändert wurden. Die bereits erstellte Schnittstelle IEntity wurde um die
Methode SetModified erweitert, die das Versionsattribut inkrementiert.

Kapitel 5
Resumee und Ausblick
5.1 Resumee
NHibernate
NHibernate macht einen soliden und ausgereiften Eindruck. Grafische Werkzeuge
zum Bearbeiten der Metadaten wären wünschenswert, aber auch nur
mit einem XML-Editor ausgestattet geht die Arbeit leicht von der Hand.
Außer den Angaben, welche Klassen und Properties persistiert werden sollen,
sind nur von Vorgabewerten abweichende Angaben zu erfassen. NHibernate
bietet eine umfangreiche Unterstützung für alle grundlegenden und
viele weitere Abbildungsszenarien. Eine großer Vorteil von NHibernate ist
die kurze und prägnante Darstellung der Metadaten für die Abbildung. Die
meisten Konstrukte werden explizit mit entsprechenden XML-Elementen
ausgedrückt (siehe z. B. Unterabschnitt 3.2.5), wodurch die Metadaten für
den Entwickler leichter zu interpretieren und entsprechend einfach zu warten
sind. Beim Entwurf der Entitätsklassen sind nur wenige Kompromisse
einzugehen, um die Anforderungen an das Framework zu erfüllen.
Ein wesentliches Manko, dessen Behebung auch von den Entwicklern
hohe Priorität beigemessen wird, ist die fehlende LINQ-Unterstützung, die
bereits in Arbeit ist und mit der nächsten Version 2.1 erwartet wird.
Genome
Genome ist ein etabliertes Produkt eines kommerziellen Anbieters. Einfaches
und effizientes Arbeiten wird durch die vorbildliche Integration in Visual
Studio ermöglicht. LINQ wird schon seit längerer Zeit unterstützt, was
untermauert, dass Genome aktiv weiterentwickelt wird. Die Metadaten sind
noch etwas übersichtlicher als bei NHibernate, was zum Teil auch daran liegt,
dass etwas weniger Abbildungsszenarien unterstützt werden. Die Auswahl
an unterstützten RDBMS lässt erkennen, dass der Fokus bei kommerziellen
Applikationen liegt.
46

5. Resumee und Ausblick 47
Die Vorgaben beim Entwurf von Entitätsklassen gehen wesentlich weiter
als bei NHibernate. Zu bemängeln ist vor allem die fehlende Unterstützung
von Beziehungen in eingebetteten Objekten.
ADO.NET Entity Framework
Wie von Microsoft gewohnt und von den Anwendern erwartet, liegt beim
ADO.NET Entity Framework ein Schwerpunkt bei der einfachen und intuitiven
Bedienung per grafischen Designer-Werkzeug und Assistenten.
Leider können mit dem grafischen Designer-Werkzeug einige grundlegende
Arbeitsschritte nicht erledigen werden. Für Applikationen, bei denen der
Objektentwurf das Datenbankmodell vorgibt, fehlt das Generieren des Datenbankschemas
aus den Metadaten (Forward engineering). Der umgekehrte
Weg, das Erstellen des konzeptionellen Modells aus dem Datenbankschema
(Reverse Engineering), kann nur beim Projektstart sinnvoll eingesetzt
werden, da manuell durchgeführte Anpassungen im konzeptionellen Modell,
dadurch überschrieben werden. Es würde genügen, diesen Vorgang so einzuschränken,
dass damit ausschließlich das Speichermodell aktualisiert wird,
denn damit wäre das Arbeiten mit dem grafischen Designer-Werkzeug halbwegs
praktikabel. Um das Entity Data Model manuell zu bearbeiten, ist es
zu komplex. Schon in den Metadaten der erstellten Beispielapplikation fällt
es schwer, sich zurechtzufinden, obwohl diese Anwendung sehr minimalistisch
ausgeführt ist.
Die Laufzeitumgebung funktioniert und die grundlegenden Abbildungsszenarien
sind realisierbar, für einfache Demonstrationen reicht es allemal.
Beim Designer-Werkzeug kann man erkennen, wie sich Microsoft den Entwurf
der Datenbankzugriffsschicht vorstellt. Für Microsoft ist es ein guter
Zeitpunkt, das Produkt öffentlich zugänglich zu machen, um Rückmeldungen
zu erhalten, wie weit die Vorstellungen der interessierten Entwickler
getroffen wurden.
Wenngleich das ADO.NET Entity Framework noch weit vom Reifegrad
von Genome oder NHibernate entfernt ist, sollte es bereits eine Verbesserung
gegenüber den bisher verfügbaren .NET-Möglichkeiten, wie z. B. Datasets,
darstellen. Vor allem die LINQ-Unterstützung trägt einen wesentlichen Teil
dazu bei. Bei komplexeren Projekten sind Genome und NHibernate zurzeit
eindeutig die bessere Wahl.
5.2 Ausblick
Wie schon der Abschnitt Grundlagen zeigt, ist das Themengebiet Objektpersistierung
vielschichtig und komplex. Einige zusätzliche Aspekte müssten untersucht
werden, um weitere wichtigen Informationen für eine entsprechende
Entscheidung zu erhalten. Dazu zählen vor allem das Verhalten unter großer

5. Resumee und Ausblick 48
Last mit vielen Datensätzen sowie verteilte Systeme. Viele Aspekte würden
trotzdem erst bei der Umsetzung konkreter Projekte zu Tage treten.
Nach der langen Entwicklungszeit bis zur ersten fertigen Version, sollte
man von Microsoft ein leistungsfähigeres Produkt, als es das ADO.NET Entity
Framework zurzeit ist, erwarten können. Die nächsten Versionen werden
zeigen, ob die Komplexität des Entity Data Model gerechtfertigt ist und neue
Möglichkeiten eröffnet oder ob damit einfach über das Ziel hinausgeschossen
wurde. Für Projekte mit einer großen Anzahl von Entitäten ist nach
Meinung des Autors, ein grafisches Designer-Werkzeug, wie der des Entity
Framework, wenig geeignet. Dazu müsste zumindest die Möglichkeit geboten
werden, mehrere Ausschnitte des konzeptionellen Modells zu erstellen,
um diese unabhängig bearbeiten zu können. Auch wenn die Laufzeitumgebung
des Entity Framework die relevanten Abbildungsszenarien bereits unterstützt,
muss sich in der Praxis erst zeigen, ob das Produkt bei steigenden
Last die notwendige Leistung erbringt.
NHibernate ist ein leistungsfähiges O/R-Mapping-Framework. Sobald
die LINQ-Unterstützung zur Verfügung steht, bleiben bei NHibernate kaum
mehr Wünsche offen. Für quelloffene Projekte wird es daher auf längere
Zeit eine gute Wahl bleiben. Mindestens so lange, bis auch freie Entwicklungsumgebungen
ein grafisches Design-Werkzeug für das Entity Framework
bieten.
Wer ein kommerzielles Produkt bevorzugt, ist zur Zeit mit Genome wesentlich
besser bedient als mit dem ADO.NET Entity Framework.
Zumindest hat Microsoft endlich ein Produkt auf dem Markt platziert,
muss sich aber an anderen Lösungen messen lassen, die für .NET sowie für
Java verfügbar sind.

Literaturverzeichnis
[Amb06a] Ambler, Scott W.: Mapping Objects to Relational Databases:
O/R Mapping In Detail. http://www.agiledata.org/essays/
mappingObjects.html. Version: Oktober 2006. – Letzter Zugriff:
2008-01-16 18:34
[Amb06b] Ambler, Scott W.: The Object-Relational Impedance Mismatch.
http://www.agiledata.org/essays/impedanceMismatch.
html. Version: Februar 2006. – Letzter Zugriff: 2008-01-16 18:38
[Bau06] Bauer, Christian: Java Persistence with Hibernate. Revised.
Manning, 2006. – 904 S. – ISBN 1932394885
[Cod90] Codd, Edgar F.: The Relational Model for Database Management
Version 2. Addison-Wesley Longman, Amsterdam, 1990. –
538 S. – ISBN 0201141922
[Dij82] Dijkstra, Edsger W.: Selected Writings on Computing: A Personal
Perspective. Springer-Verlag, 1982. – 362 S. – ISBN
0387906525
[Esp04] Esposito, Dino: A First Look at ObjectSpaces in Visual Studio
"Whidbey". http://msdn2.microsoft.com/en-us/library/ms971512.
aspx. Version: Februar 2004. – Letzter Zugriff: 2008-01-19 10:49
[Eva03] Evans, Eric: Domain-Driven Design: Tackling Complexity in the
Heart of Software. 1. A. Addison-Wesley Longman, Amsterdam,
2003. – 560 S. – ISBN 0321125215
[FRF02] Fowler, Martin ; Rice, David ; Foemmel, Matthew: Patterns
of Enterprise Application Architecture. Addison-Wesley Longman,
Amsterdam, 2002 (A Martin Fowler Signatur Book). – 560
S. – ISBN 0321127420
[Fus97] Fussell, Mark L.: Foundations of Object Relational
Mapping. http://www.chimu.com/publications/objectRelational/
objectRelational.pdf. Version: Juli 1997
49

Literaturverzeichnis 50
[GHJV04] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides,
John: Entwurfsmuster: Elemente wiederverwendbarer objektorientierter
Software. Addison-Wesley, München, 2004. – 479 S. –
ISBN 3827321999
[KB04] King, Gavin ; Bauer, Christian: Hibernate in Action: Practical
Object/Relational Mapping. Manning, 2004. – 408 S. – ISBN
193239415X
[KBK08] Kuate, Pierre ; Bauer, Christian ; King, Gavin: Nhibernate
in Action. MEAP 2008-08-04. Manning, 2008. – 560 S. – ISBN
1932394923
[MN02] Moses, Daniel ; Nowak, Johannes: Programmieren unter .net.
C# Edition. Franzis Verlag, 2002. – 645 S. – ISBN 3772372244
[Nil02] Nilsson, Jimmy: InformIT: The Cost of GUIDs as Primary
Keys > Natural or Surrogate Keys. http://www.informit.com/
articles/article.aspx?p=25862. Version: März 2002. – Letzter Zugriff:
2008-07-04 16:11
[Nil06] Nilsson, Jimmy: Applying Domain-Driven Design and Patterns:
With Examples in C# and .NET. Addison-Wesley Longman,
Amsterdam, 2006. – 576 S. – ISBN 0321268202
[Pap07] Papa, John: Datenpunkte: Übersicht über ADO.NET Entity Framework.
http://msdn.microsoft.com/de-de/magazine/cc163399.
aspx. Version: Juli 2007. – Letzter Zugriff: 2008-09-04 18:20
[RNG + 04] Robinson, Simon ; Nagel, Christian ; Glynn, Jay ; Allen,
K. S. ; Cornes, Ollie ; Greenvoss, Zach ; Harvey, Burton ;
Skinner, Morgan ; Watson, Karli: Professional C sharp. 2nd
Edition. Wiley & Sons, 2004. – 1270 S. – ISBN 1861007043
[Sch07] Schwichtenberg, Dr. H.: iX - 07.06.06 - Microsoft und das
OR-Mapping: Es bleibt kurios. http://www.heise.de/ix/Microsoftund-das-OR-Mapping-Es-bleibt-kurios--/blog/artikel/73937.
Version: Juni 2007. – Letzter Zugriff: 2008-08-30 13:57
[Sch08] Schwichtenberg, Dr. H.: iX - 28.08.08 - LINQ-to-SQL versus
ADO.NET Entity Framework. http://www.heise.de/ix/LINQ-to-
SQL-versus-ADO-NET-Entity-Framework--/blog/artikel/115087.
Version: August 2008. – Letzter Zugriff: 2008-08-29 12:12

Web-Referenzen
[1] Allchin, J. : Jim Allchin: Microsoft Professional Developers
Conference 2005. http://www.microsoft.com/presspass/exec/Jim/09-
13PDC2005.mspx. Version: Sept. 2005. – Letzter Zugriff: 2008-06-18
14:03
[2] Apple: WebObjects Enterprise Objects Programming Guide: Introduction
to WebObjects Enterprise Objects Programming Guide.
http://developer.apple.com/documentation/WebObjects/Enterprise_
Objects/About/chapter_1_section_1.html. Version: Jul. 2007. – Letzter
Zugriff: 2008-01-19 09:45
[3] Bauer, C. : [Hibernate] NHibernate joins Hibernate at JBoss
Inc. http://www.mail-archive.com/hibernate-devel@lists.sourceforge.net/
msg05094.html. – Letzter Zugriff: 2008-09-03 12:16
[4] Ben-Ami, N. : ADO.NET team blog : Update Model From
DB. http://blogs.msdn.com/adonet/archive/2008/04/01/update-modelfrom-db.aspx.
Version: Apr. 2008. – Letzter Zugriff: 2008-09-15 13:52
[5] Blakeley, J. ; Campbell, D. ; Gray, J. ; Muralidhar, S. ; Nori,
A. : Next-Generation Data Access: Making the Conceptual Level
Real. http://msdn.microsoft.com/en-us/library/aa730866(vs.80).aspx.
Version: Jun. 2006. – Letzter Zugriff: 2008-06-18 14:14
[6] Bouma, F. : Why change-tracking has to be part of an entity object
- Frans Bouma’s blog. http://weblogs.asp.net/fbouma/archive/2007/
04/03/why-change-tracking-has-to-be-part-of-an-entity-object.aspx.
Version: Apr. 2007. – Letzter Zugriff: 2008-07-14 15:25
[7] Devart: Devart News: New Software Releases, Company News
and Press Releases. http://devart.com/news/2008/directs475.html.
Version: Aug. 2008. – Letzter Zugriff: 2008-09-14 13:51
[8] Esposito, D. : ObjectSpaces - Dino Esposito’s WebLog. http://weblogs.
asp.net/despos/archive/2004/01/21/61052.aspx. Version: Jan. 2004. –
Letzter Zugriff: 2008-06-18 13:16
51

Web-Referenzen 52
[9] ICSharpCode: SharpDevelop @ic#code. http://sharpdevelop.net/
OpenSource/SD/. Version: Jul. 2008. – Letzter Zugriff: 2008-07-10 13:19
[10] Jones, L. : ADO.NET team blog : Update Model – a Question of Identity
– Part 1 of 3. http://blogs.msdn.com/adonet/archive/2008/07/21/
update-model-a-question-of-identity-part-1-of-3.aspx. Version: Jul. 2008.
– Letzter Zugriff: 2008-09-15 13:45
[11] Kaufmann, M. : ADO.NET team blog : EDM Tools | Options (Part
1 of 4). http://blogs.msdn.com/adonet/archive/2008/06/20/edm-toolsoptions-part-1-of-4.aspx.
– Letzter Zugriff: 2008-08-06 10:37
[12] Kovacs, J. : James Kovacs’ Weblog - Enabling Intellisense
for NHibernate. http://www.jameskovacs.com/blog/
EnablingIntellisenseForNHibernate.aspx. Version: Okt. 2007. – Letzter
Zugriff: 2008-09-14 18:56
[13] Kulkarni, D. ; Bolognese, L. ; Warren, M. ; Hejlsberg, A. ;
George, K. : LINQ to SQL: .NET Language-Integrated Query for Relational
Data. http://msdn.microsoft.com/en-us/library/bb425822.aspx.
Version: März 2007. – Letzter Zugriff: 2008-09-02 11:02
[14] Mallalieu, T. : Entity Framework Design : Transparency in the
design process. http://blogs.msdn.com/efdesign/archive/2008/06/23/
transparency-in-the-design-process.aspx. – Letzter Zugriff: 2008-07-24
22:31
[15] Mallalieu, T. : Entity Framework Design : Initial POCO Design
1-Pager. http://blogs.msdn.com/efdesign/archive/2008/06/24/initialpoco-design-1-pager.aspx.
Version: Jun. 2008. – Letzter Zugriff: 2008-
07-24 22:26
[16] Mallalieu, T. : Tim Mallalieu’s Blog. : To Lazy Load or not to Lazy
load? http://blogs.msdn.com/timmall/archive/2008/06/24/to-lazy-loador-not-to-lazy-load.aspx.
Version: Jun. 2008. – Letzter Zugriff: 2008-07-
24 21:54
[17] Mallalieu, T. : Tim Mallalieu’s Blog. : Vote of No Confidence.http://blogs.msdn.com/timmall/archive/2008/06/24/vote-of-noconfidence.aspx.
Version: Jun. 2008. – Letzter Zugriff: 2008-07-24 22:01
[18] Microsoft: ADO.NET Entity Framework and LINQ to Entities
(Pre-release) - MSDN Forums. http://forums.microsoft.com/MSDN/
ShowForum.aspx?ForumID=533\&SiteID=1. – Letzter Zugriff: 2008-09-
02 17:15

Web-Referenzen 53
[19] Microsoft: Customizing Objects (Entity Framework). http://msdn.
microsoft.com/en-us/library/bb738612.aspx. – Letzter Zugriff: 2008-10-
28 09:36
[20] Microsoft: Entity Framework Design. http://blogs.msdn.com/
efdesign/default.aspx. – Letzter Zugriff: 2008-07-25 11:56
[21] Microsoft: Entity Framework Features. http://msdn.microsoft.com/
en-us/library/bb896338.aspx. – Letzter Zugriff: 2008-07-21 14:36
[22] Microsoft: How to: Implement Custom Data Class Interfaces (Entity
Framework). http://msdn2.microsoft.com/en-us/library/bb738453.aspx.
– Letzter Zugriff: 2008-06-17 15:56
[23] Microsoft: Reference Source Service. http://www.microsoft.com/
resources/sharedsource/referencesource.mspx. – Letzter Zugriff: 2008-09-
04 10:14
[24] Microsoft: Saving Changes and Managing Concurrency (Entity
Framework). http://msdn.microsoft.com/en-us/library/bb738618.aspx. –
Letzter Zugriff: 2008-07-21 14:38
[25] Microsoft: Schemas and Mapping Specification (Entity Framework).
http://msdn.microsoft.com/en-us/library/bb399604.aspx. – Letzter Zugriff:
2008-09-04 17:51
[26] Microsoft: Visual Studio 2008 and .NET Framework 3.5 Service Pack
1. http://msdn.microsoft.com/en-us/vstudio/products/cc533447.aspx. –
Letzter Zugriff: 2008-09-02 11:20
[27] Microsoft: The ADO.NET Entity Framework Overview. http://
msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx. Version: Jun.
2006. – Letzter Zugriff: 2008-07-10 10:50
[28] Microsoft: Download details: Visual Studio 2008 Service Pack
1 (Installer). http://www.microsoft.com/downloads/details.aspx?
familyid=FBEE1648-7106-44A7-9649-6D9F6D58056E\&displaylang=en.
Version: Aug. 2008. – Letzter Zugriff: 2008-09-02 11:37
[29] Microsoft: Download details: Visual Studio 2008 Service Pack 1 (iso).
http://www.microsoft.com/downloads/details.aspx?familyid=27673C47-
B3B5-4C67-BD99-84E525B5CE61\&displaylang=en. Version: Aug.
2008. – Letzter Zugriff: 2008-09-02 11:37
[30] Microsoft: Download details: VS 2008 Service Pack Preparation Tool.
http://www.microsoft.com/downloads/details.aspx?familyid=A494B0E0-
EB07-4FF1-A21C-A4663E456D9D\&displaylang=en. Version: Aug.
2008. – Letzter Zugriff: 2008-09-02 11:38

Web-Referenzen 54
[31] Microsoft: The LINQ Project. http://msdn.microsoft.com/en-us/
netframework/aa904594.aspx. Version: Jul. 2008. – Letzter Zugriff: 2008-
07-10 09:20
[32] Microsoft: Overview: ADO.NET Data Services. http://msdn.
microsoft.com/en-us/library/cc956153.aspx. Version: Aug. 2008. – Letzter
Zugriff: 2008-09-28 15:36
[33] Mono: Main Page - Mono. http://www.mono-project.com/Main_Page.
Version: Jul. 2008. – Letzter Zugriff: 2008-07-10 13:08
[34] Noras, A. : Anders Noras’ Blog : IPoco? http://andersnoras.com/
blogs/anoras/archive/2007/07/03/ipoco.aspx. Version: Jul. 2007. – Letzter
Zugriff: 2008-09-23 23:15
[35] ODMBS.OG: ODBMS.ORG :: Object Database (ODBMS) | Object-
Oriented Database (OODBMS) | Free Resource Portal. http://www.
odbms.org/odmg.html. Version: Jul. 2008. – Letzter Zugriff: 2008-07-14
13:47
[36] Oracle: Oracle 11g, Siebel, PeopleSoft | Oracle, The World’s Largest
Enterprise Software Company. http://www.oracle.com/index.html.
– Letzter Zugriff: 2008-09-14 18:03
[37] Oracle: Oracle TopLink. http://www.oracle.com/technology/
products/ias/toplink/index.html. Version: Jun. 2008. – Letzter Zugriff:
2008-06-17 16:37
[38] PostgreSQL: PostgreSQL: The world’s most advanced open source
database. http://www.postgresql.org/. – Letzter Zugriff: 2008-09-14
18:47
[39] RedHat: Chapter 16. Toolset Guide. http://www.hibernate.org/hib_
docs/nhibernate/1.2/reference/en/html/toolsetguide.html. – Letzter Zugriff:
2008-10-26 16:47
[40] RedHat: hibernate.org - Databases supported by NHibernate. http:
//www.hibernate.org/361.html. – Letzter Zugriff: 2008-09-03 13:38
[41] RedHat: hibernate.org - Hibernate. http://www.hibernate.org/. – Letzter
Zugriff: 2008-09-12 19:45
[42] RedHat: hibernate.org - NHibernate Resources. http://www.hibernate.
org/365.html. – Letzter Zugriff: 2008-01-06 00:04
[43] RedHat: hibernate.org - Road Map. http://www.hibernate.org/357.
html#A14. – Letzter Zugriff: 2008-09-03 13:31

Web-Referenzen 55
[44] RedHat: jboss.org: community driven. http://www.jboss.org/. – Letzter
Zugriff: 2008-09-03 11:56
[45] RedHat: redhat.com | Home. https://www.redhat.com/. – Letzter
Zugriff: 2008-09-03 11:57
[46] RedHat: hibernate.org - NHibernate for .NET. http://www.hibernate.
org/343.html. Version: Jan. 2008. – Letzter Zugriff: 2008-01-05 23:39
[47] Sceppa, D. : ADO.NET team blog : SQLite’s ADO.NET
Provider Supports the ADO.NET Entity Framework! http:
//blogs.msdn.com/adonet/archive/2008/09/06/sqlite-s-ado-netprovider-supports-the-ado-net-entity-framework.aspx.
Version: Sept.
2008. – Letzter Zugriff: 2008-09-14 18:07
[48] Security, A. A.: SQL Anywhere 11: Schneller Support für
ADO.NET Entity Framework und LINQ - All About SECURI-
TY. http://www.all-about-security.de/security-artikel/applikations-hostsicherheit/backend-systeme-datenbanken/artikel/6784-sql-anywhere-
11-schneller-support-fuer-adonet-entity-framew/. – Letzter Zugriff:
2008-08-06 18:53
[49] Simmons, D. : system.data.objects dev guy : EF Persistence Ignorance
Recap. http://blogs.msdn.com/dsimmons/archive/2007/09/26/efpersistence-ignorance-recap.aspx.
Version: Sept. 2007. – Letzter Zugriff:
2008-01-14 21:27
[50] Simmons, D. : system.data.objects dev guy : "June"CTP of the
Entity Framework is finally out. http://blogs.msdn.com/dsimmons/
archive/2007/07/03/june-ctp-of-the-entity-framework-is-finally-out.aspx.
Version: Jul. 2007. – Letzter Zugriff: 2008-09-15 11:58
[51] Simmons, D. ; NTDeveloper ; Hoffman, K. : Persistence Ignorance
in the Entity Framework - MSDN Forums. http://forums.
microsoft.com/MSDN/ShowPost.aspx?PostID=1339491\&SiteID=1.
Version: März 2007. – Letzter Zugriff: 2008-09-15 13:24
[52] Smith, D. : A Brief History of TopLink. http://www.oracle.com/
technology/tech/java/newsletter/articles/toplink/history_of_toplink.
html. Version: Jun. 2008. – Letzter Zugriff: 2008-06-17 16:32
[53] SQLite: SQLite Home Page. http://www.sqlite.org/. – Letzter Zugriff:
2008-09-14 18:21
[54] SunMicrosystems: MySQL :: Die populärste Open-Source-Datenbank
der Welt. http://www.mysql.de/. – Letzter Zugriff: 2008-09-14 18:23

Web-Referenzen 56
[55] SunMicrosystems: Java Persistence API. http://java.sun.com/
javaee/technologies/persistence.jsp. Version: Jun. 2008. – Letzter Zugriff:
2008-06-18 12:35
[56] Team, A. : ADO.NET team blog : What’s New in the SP1 Beta?http://blogs.msdn.com/adonet/archive/2008/05/12/what-s-new-inthe-sp1-beta.aspx?CommentPosted=true#commentmessage.
– Letzter
Zugriff: 2008-07-24 22:54
[57] Team, A. : ADO.NET team blog : Third Party Provider Support for the
Entity Framework RTM. http://blogs.msdn.com/adonet/archive/2008/
08/11/third-party-provider-support-for-the-entity-framework-rtm.aspx.
Version: Aug. 2008. – Letzter Zugriff: 2008-09-02 16:25
[58] Team, A. : Project Astoria Team Blog. http://blogs.msdn.com/
astoriateam/. – Letzter Zugriff: 2008-09-28 15:27
[59] TechTalk: Genome > Home. http://www.genom-e.com/.
Version: Jun. 2008. – Letzter Zugriff: 2008-06-17 19:39
[60] TechTalk: Welcome @ TechTalk. http://web.techtalk.at/.
Version: Sept. 2008. – Letzter Zugriff: 2008-09-02 15:56
[61] Unbekannt: Hibernate History at SourceForge.net. http://sourceforge.
net/news/?group_id=40712. – Letzter Zugriff: 2008-09-03 11:30
[62] Unbekannt: Interview with Gavin King, founder of Hibernate. :: JavaFree.
http://www.javafree.org/content/view.jf?idContent=3. – Letzter
Zugriff: 2008-09-03 11:09
[63] Unbekannt: System.Data.SQLite. http://sqlite.phxsoftware.com/. –
Letzter Zugriff: 2008-09-11 19:03
[64] Unbekannt: ADO .NET Entity Framework Vote of No Confidence.http://efvote.wufoo.com/forms/ado-net-entity-framework-voteof-no-confidence/.
Version: Jun. 2008. – Letzter Zugriff: 2008-06-24
23:46
[65] Whitehead, N. : Hibernate Joins JBoss Group. http://www.
theserverside.net/discussions/thread.tss?thread_id=21482. – Letzter Zugriff:
2008-09-03 11:45