Historisch gesehen waren Datenbanken

Transkript

1 Das Domain Model Pattern mit dem Entity Framework 2.0 umsetzen Reine Modellierung Komplexe Applikationen erfordern eine klare Trennung der Schichten Datenzugriff, Geschäftslogik und Benutzer - schnittstelle. Eine besondere Herausforderung ist die Trennung der Geschäftsobjekte von der Persistenz schicht. Das Entity Framework 2.0 ermöglicht es, das Domain Model Pattern in seiner reinen Form umzusetzen. Auf einen Blick Dino Esposito ist Architekt bei IDesign und Autor zahlreicher Programmierbücher, darunter etwa kürzlich Microsoft.NET: Architecting Applications for the Enterprise und Programming ASP.NET 3.5 Core Reference, beide bei Microsoft Press erschienen. Dino ist auch häufig Sprecher auf Entwicklerevents wie etwa DevConnections, Basta, DevWeek oder Microsoft TechEd und international anerkannter Trainer und Consultant. Manchmal bloggt er unter weblogs.asp.net/despos. Inhalt Das Domain Model Pattern mit dem Entity Framework 2.0 umsetzen. Das Domänenmodell aus POCO-Klassen aufbauen (Plain Old CLR Object). Mit dem Entity Framework 2.0 vom Domänenmodell das benötigte Datenbankschema generieren lassen. Grundlagen Das ADO.NET Entity Framework, QdnpCodeA0705EntityFramework Architekturmuster für die Problemdomäne, QdnpCodeA0812DDD dnpcode A0910EF20 Historisch gesehen waren Datenbanken für die Entwicklung von Applikationen von erheblich größerer Bedeutung als Klassen. Viele Jahre lautete die vorherrschende Strategie: Erst das Design der Datenbank er - stellen, dann eine Bibliothek von Klassen drum herum entwickeln. Dieser datenbankzentrierte Zugang hatte seinen Grund in der leichten Verfügbarkeit von relationalen Datenbanken, aber auch darin, dass die Komplexität der Software kompatibel war zur Ausdrucksstärke des relationalen Datenmodells. Diese datenzentrierte Herangehensweise an die Entwicklung von Unternehmenssoftware war in den vergangenen zehn Jahren der übliche Weg, Mehrschichtanwendungen zu erstellen. Aber vor zehn Jahren war das Szenario im Vergleich zu heute völlig anders. Komplexere Applikationen erfordern es, das relationale Modell einer Überprüfung zu unterziehen, wenn nicht für die Speicherung, so doch zumindest für die Datenmodellierung. Vor zehn Jahren waren die besten und schnellsten Computer in einem Unternehmen gewöhnlich diejenigen, auf denen ein Datenbankmanagementsystem lief wie etwa SQL Server, DB2 oder Oracle. Objektorientierung steckte noch in den Kinderschuhen, zumindest was die Microsoft- Plattform betraf. (C# war die erste, einfach zu benutzende objektorientierte Sprache von Microsoft, und sie erschien im Jahr 2002.) Sich ein System vorzustellen als eine Datenbank mit etwas Geschäftscode drum herum war eine ausgezeichnete Denkweise. Und viele Entwickler haben eine Menge Systeme auf diese Weise erstellt. Stored Procedures waren das beste Werkzeug, und Logik in Stored Procedures zu speichern erschien als gut und vernünftig. Aspekte wie etwa Sicherheit in die Geschäftslogik aufsteigen zu lassen, wirkte deplatziert und ging mit einem deutlichen Verlust von Performance einher. Da alles in die Datenbank gepackt wurde, erschien die Modellierung realer Daten als zweitrangige Aufgabe. Das einzige Datenmodell, das zählte, war das Tabellenmodell der Datenbank; Applikationen mussten damit zurechtkommen. Dementsprechend konnten diejenigen Datentypen, die auf Applikationsebene Daten speichern und durch die Schichten durchreichen, nur datenbankähnliche Container sein, also Recordsetähnliche Datenstrukturen. Im.NET Framework bedeutete das, die Typen DataSet und DataTable zu nutzen, um Domänendaten zu modellieren, die in einer relationalen Datenbank gespeichert werden sollten. Heute leben wir in einer gänzlich anderen IT- Welt; die Komplexität von Unternehmensapplikationen erfordert eine andere Herangehens weise an die Datenmodellierung. Während für die Speicherung der Daten nach wie vor überwiegend relationale Datenbanken zum Einsatz kommen und objektorientierte DBMS (ODBMS) eine ferne Vision bleiben, stellt sich die objektorientierte Repräsentation der Domänendaten mehr und mehr als die effektivere Form heraus. Eine konzeptionelle Beschreibung der Entitäten und ihrer Beziehungen in einer vorgegebenen Problemdomäne ermöglicht Ihnen als Architekt, die komplizierten Vorgänge der echten Welt zuverlässiger und leichter abzubilden. Das konzeptionelle Modell der Domäne, das nicht unmittelbar an ein physisches Speicherschema geknüpft ist, führt Sie gleichzeitig direkt zu einem neuen Muster für den Entwurf und die Entwicklung von Anwendungen und bringt die Notwendigkeit neuer Werkzeuge mit sich. Ein wichtiges Werkzeug in der.net-welt ist in dieser Hinsicht das Entity Framework (EF) 2.0. Ein Modell der fachlichen Domäne In einer konzeptionellen Beschreibung eines Systems konzentrieren Sie sich auf die Entitäten mit all ihren Beziehungen, Daten und ihrem Verhalten. Ihnen als Architekt helfen in der Regel die Domänenexperten meistens des Kunden in Ihren Bemühungen, ein Modell für das reale System zu entwerfen. Das Domänenmodell-(DM)- Pattern bietet Orientierung darin, wie sich die Komplexität einer Problemdomäne über einen Graph aufeinander bezogener Klassen aus - drücken lässt. Sie erarbeiten eine Repräsentation des Systems in Form von Software-Entitäten, und dabei stützen Sie sich auf das Verhalten und auf die Daten realer Entitäten. Wenn Sie die Geschäftslogik nach dem Domain- Model-Pattern organisieren, dann zielt diese Art des Softwaredesigns darauf, mit Komplexität auf

2 [Abb. 1] Je komplexer die Domäne, desto eher rentiert sich das Domain-Model-Pattern. überschaubare und komfortable Art und Weise umzugehen. Ein Domain-Model-Pattern zu implementieren bedeutet in erster Linie, ein Objektmodell zu erstellen, das ein konzeptionelles Modell des Systems repräsentiert. Dieses Objektmodell wird als Domänenmodell bezeichnet. Das Domänenmodell beschreibt die Entitäten, die an dem System teilnehmen, und bildet zugleich alle Beziehungen und Datenflüsse zwischen ihnen ab. Das Domänenmodell ist ein spezieller Typ von Objektmodell, bei dem Klassen spezifische Anforderungen erfüllen: Es sind einfache.net-objekte, es gibt keine Abhängigkeiten zu externen Klassen und Interfaces, und sie kümmern sich nicht um Persistenz. Das Domänenmodell ist ein Schlüsselbestandteil innerhalb des Projekts, bei dem Sie in der Regel in zwei Schritten vorgehen. Zunächst ist das Domänenmodell ein formales Modell, das Teams aus Technikern und Domänenexperten zusammen erarbeiten. Wenn es ihnen gelungen ist, dieses Modell gemeinsam zu erstellen, dann heißt das, dass sich die Leute von der Technik und die Leute von der Geschäftsdomäne auf ein gemeinsames Verständnis des Problems geeinigt haben. Zu diesem Zeitpunkt ist das Domänenmodell noch kein Stück Software, und es enthält kein Konzept oder Prinzip, das in irgendeiner Weise spezifisch für Software oder eine bestimmte Implementierung ist. Von diesem abstrakten Domänenmodell ausgehend bewegen Sie sich auf etwas zu, was Martin Fowler ein Netz miteinander verbundener Objekte nennt so nach - zulesen in seiner formalen Definition des Domain-Model-Patterns in seinem Buch Patterns of Enterprise Application Architecture (Addison-Wesley). Zu diesem Zeitpunkt entstehen aus den Entitäten des Domänenmodells Klassen mit einem passenden Satz von Methoden und Eigenschaften. Alle Bestandteile des Domänenmodells werden in Klassen mit eigenem Verhalten abgebildet, einschließlich solcher Entitäten wie Kunden, Rechnungsposten, Adressen, Kontaktinformationen und so weiter. Ein Domänenmodell ist vollkommen unabhängig von der Datenbank. Um das Domain-Model-Pattern erfolgreich anzuwenden, ist die enge Zusammenarbeit zwischen Softwarearchitekten und Domänenexperten von zentraler Wichtigkeit. Es muss sichergestellt sein, dass die Geschäftsprozesse in allen Aspekten verstanden und die Anforderungen an die Software korrekt und vollständig beschrieben sind. Da Systeme letzten Endes aber auf Software und Datenbanken basieren, muss sich zu einem bestimmten Zeitpunkt jemand darum kümmern, das abstrakte Modell auf ein ausführbares Objektmodell abzubilden und es in einer (relationalen) Datenbank zu speichern. Genau das macht die Umsetzung des DM-Patterns so aufwendig, aber zugleich ist es der Grund dafür, warum diese Herangehensweise erheblich mächtiger ist als andere Methoden, die Geschäftsschicht zu organisieren. Abbildung 1 ist aus einer analogen Dar - stellung in dem bereits erwähnten Buch von Martin Fowler hervorgegangen. Sie zeigt den Entwicklungsaufwand, der bei Verwendung unterschiedlicher Muster für die Entwicklung der Geschäftslogik entsteht, im Vergleich. Wie Sie sehen, ist der grundlegende Aufwand für das DM-Pattern erheblich höher als für ein tabellenbasiertes Pattern wie etwa Table Module. Wenn die Komplexität der Domänenlogik steigt, steigt der Aufwand beim DM-Pattern linear an, wohingegen sich die Kurve des Table- Module-Patterns an irgendeinem (relativ frühen) Punkt einer vertikalen Asymptote annähert. Das Table-Module-Pattern basiert auf der Idee, die Tabellen eines realen Speicherschemas in Objekten zu repräsentieren. Sie erstellen für jede Tabelle der Datenbank ein Objekt und rufen Methoden auf diesen Objekten auf, um Queries und Updates auf dem Datenspeicher auszuführen. Auf diese Weise implementieren Sie die erforderliche Geschäftslogik. Das Table-Module-Pattern ist in Visual Studio 2005 und Visual Studio 2008 in den Assistenten implementiert, die typisierte Data- Sets und TableAdapter erzeugen. In Visual Studio 2008 SP1 und noch besser in Visual Studio 2010 finden Sie weitere Designtools vor, die Sie zum Domain- Model-Pattern hinführen. Diese Designtools gehören zum Entity Framework. Das Entity Framework 2.0 Um das Domain-Model-Pattern zu implementieren, sind zwei Schritte notwendig: Sie müssen das Objektmodell erstellen und die dabei entstehenden Klassen auf Datenbanktabellen und -spalten abbilden. Im Entity Framework finden Sie einen De - signer, um das Netz der miteinander verbundenen Objekte zu erzeugen, und einen weiteren Designer, mit dem Sie Objekte auf Datenbanktabellen abbilden können. Zusätzlich bietet das Framework eine Schicht mit einem O/R-Mapper, der das resultierende Modell in den ausgewählten physischen Tabellen speichert. Als Technologie ist das Entity Framework ein O/R-Mapper mit einigen Erweiterungen. Ein O/R-Mapper ist letztlich nur eine Software, die von einem Graph reiner.net- Objekte ausgeht, eine Mapping-Datei verwendet und ein API anbietet, mit dem sich Klasseninstanzen in Datenbanktabellen speichern lassen. Das Entity Framework ist aber noch etwas ehrgeiziger. Die Integration in Visual Studio ermöglicht es, das Domänenmodell und die entsprechenden Datenbank-Mappings in der vertrauten Umgebung mit mächtigen visuellen Designern zu erzeugen. Das dar - aus resultierende Domänenmodell (als Entity Data Model bezeichnet) ist als Klassen bibliothek auch für viele andere Microsoft-Produkte verfügbar, einschließlich ADO.NET-Data-Services und Reporting- Werkzeugen. Abbildung 2 zeigt eine Übersicht über das Entity Framework

3 _Das Domain Model Pattern mit dem Entity Framework 2.0 umsetzen [Abb. 2] Das Entity Framework in der Übersicht. Sie teilen dem Assistenten mit, dass er ein brandneues Domänenmodell erzeugen soll, das später auf eine neue Datenbank abgebildet werden soll. In einer domänenorientierten Welt ist die Schicht mit der Geschäftslogik klar getrennt von der Datenzugriffsschicht. Die Daten und das Verhalten von Objekten sind in der einen Assembly enthalten. Der Code für die Persistenz ist einer anderen Assembly zugeordnet. In einer domänenorientierten Welt hat die Datenzugriffsschicht ihre eigenen wohl definierten Verantwortlichkeiten. Wer erstellt die Datenzugriffsschicht? Die Datenzugriffsschicht kann natürlich vom gleichen Entwicklungsteam erstellt werden, das auch das Domänenmodell erstellt. In einer domänenorientierten Welt ist das harte Arbeit. Da hier aber in der Regel keine anwendungsspezifischen Aspekte enthalten sind, ist Raum vorhanden für Persistenzwerkzeuge wie O/R-Mapper. In einer domänenorientierten Welt ist eine gut gebaute Datenzugriffsschicht beinahe das Gleiche wie ein gut gebauter O/R-Mapper. Aber es ist kaum sinnvoll, für jede Applikation einen eigenen O/R-Mapper zu schreiben. Um mit dem Domain-Model-Pattern zu arbeiten, benötigen Sie letztlich ein objektbasiertes Datenmodell und einen O/R- Mapper. Entsprechende Designer sind das Tüpfelchen auf dem i. Und all das bietet das Entity Framework. Das Entity Framework bei der Arbeit Das Entity Framework verwenden Sie, wenn Sie das Modell für domänenspezifische Daten definieren müssen. Das Modell zu definieren bedeutet letztlich, relevante Entitäten und ihre Verknüpfungen zu identifizieren. In.NET ist dieses Modell nichts weiter als eine Assembly. Typischerweise beginnen Sie, indem Sie ein Projekt mit einer Klassenbibliothek erzeugen und dann ein neues Item vom Typ ADO.NET Entity Data Model hinzufügen, siehe Abbildung 3. Die für Sie generierte EDMX-Datei repräsentiert die Beschreibung des Domänenmodells. Sie haben zwei Optionen: Sie können ein Modell entsprechend einer vorhandenen Datenbank erzeugen lassen, oder Wenn Sie von einer vorhandenen Datenbank ausgehen, geben Sie den Connection- String an und lassen den Assistenten alle Details aus der lokalen oder entfernten Datenbank beziehen. Als Ergebnis reflektiert das EDMX-Modell genau den Inhalt der Datenbanktabellen. Im Endeffekt erhalten Sie eine Entität für jede ausgewählte Tabelle oder Sicht. Diese Repräsentation können Sie natürlich weiter anpassen und jederzeit bearbeiten. Diese Vorgehensweise wird auch im Entity Framework 1.0, das in Visual Studio 2008, Service Pack 1 enthalten ist, vollständig unterstützt. Das andere Szenario mit einem leeren Datenmodell zu beginnen ist eine neue, sehr leistungsstarke Option in Visual Studio 2010, die im Folgenden untersucht werden soll. So wie es in Abbildung 4 zu sehen ist, können Sie dem Modell Entitäten und Assoziationen hinzufügen. Eine Entität ist im Wesentlichen die Beschreibung einer Klasse, und sie besteht aus einer Liste von Eigenschaften. Eine Assoziation ist eine Verbindung zwischen zwei Entitäten, die an beiden Enden unterschiedliche Wertigkeiten haben kann: eins, eins oder null, viele. Die Assoziation hat einen Namen und erzeugt in beiden Entitäten eine neue Referenz-Eigenschaft. Eine Eigenschaft kann einen Standardwert haben, natürlich einen Typ, einige [Abb. 3] Ein ADO.NET Entity Data Model hinzufügen. [Abb. 4] In einem Entity-Framework-2.0-Modell Entitäten und Assoziationen hinzufügen

4 [Abb. 5] Der Eigenschaft einer Entität einen komplexen Typ zuweisen. Attribute, die die Sichtbarkeit der Get- und Set-Methoden betreffen, und eine Schlüsselreferenz. Der Typ kann insbesondere entweder ein skalarer Typ sein wie String/Integer oder ein komplexer Typ wie etwa ein selbst definierter.net-typ. Abbildung 5 zeigt die konzeptionelle Definition des Typs Address- Info für die Eigenschaft Address des Clients. Das Datenmodell der Entitäten zu entwerfen ist nur der erste Schritt. Als Nächstes müssen Sie die Eigenschaften auf die Tabellenspalten einer konkreten Datenbank abbilden. Das Entitäten-Datenmodell wird in einer XML-Datei abgelegt, die die Conceptual Schema Definition Language (CSDL) nutzt. Der physische Datenspeicher wird modelliert und erstellt mithilfe der Storage Schema Definition Language (SSDL). Und die Definition des Mappings zwischen den beiden Schemas wird schließlich mithilfe der Mapping Specification Language (MSL) bewerkstelligt. Die Designer in Visual Studio ermöglichen es Ihnen, das konzeptionelle und das physische Modell zu entwerfen und ein Mapping durchzuführen, ohne dass Sie sich mit XML auskennen müssen, aber jetzt wissen Sie, was sich unter der Haube abspielt. Das Datenbankschema generieren Wie bereits erwähnt unterstützt das Entity Framework zwei Engineering-Modelle. Sie können ein Reverse-Engineering der Datenbank durchführen und damit das Entitätenmodell von einem vorhandenen Schema ableiten. Alternativ können Sie mit einem Forward-Engineering den Designer von Visual Studio 2010 dazu veranlassen, ausgehend von einem existierenden Entitätenmodell passende SQL-Skripte zu erzeugen, die die passenden Datenbank - tabellen erstellen. Wenn Sie von einem Entitätenmodell ausgegangen sind, dann werden Sie so wie in Abbildung 6 ein fertig ausführbares SQL- Skript erhalten. Damit ist es an Ihnen, dieses Skript in der darunterliegenden Datenbank zu laden und auszuführen. Für das leichtere Handling wird der Connection- String für die Datenbank in einer Konfigurationsdatei abgelegt. Diese können Sie in ein Zielprojekt kopieren oder mit der Konfigurationsdatei des Projekts, das das Entitätenmodell nutzt, zusammenführen. Die meisten Mappings werden automatisch ausgeführt, ohne dass Sie sich einschalten und Dinge manuell auflösen müssen. Mit den Designern des Entity Frameworks ist es nicht möglich, die Eigenschaften von Klassen auf die Spalten einer bereits existierenden Datenbanktabelle abzubilden. Sie können nur entweder von einer existierenden Datenbank ausgehen und das Modell von dort aus aufbauen oder ein Skript erzeugen lassen, das seinerseits die passende Datenbank generiert. Im Ergebnis heißt das, dass das Entity Framework eine ausgezeichnete Wahl ist, wenn Sie ein Domain-Model-Projekt von Grund auf neu aufsetzen können und wenn Sie keinen Legacy-Code und keine POCO und der generierte Code Zur ersten Version des Entity Frameworks und zu den Einschränkungen, die sie den Entity-Klassen auferlegt, wurde an anderer Stelle bereits viel gesagt. Im Entity Framework 1 müssen Entity-Klassen insbesondere von der Klasse EntityObject ableiten, die das System zur Verfügung stellt. Alternativ kann eine Entity-Klasse einen Satz von Schnittstellen implementieren, dazu gehören IEntityWithKey, IEntityWithChange- Tracker und IEntityWithRelationships. Am Rande sei erwähnt, dass diese Schnitt - stellen allgemein als IPOCO bekannt sind, wobei POCO die verbreitete Abkürzung für Plain Old CLR Object ist. Indem die Klassen des Domänenmodells von einer Systembasisklasse ableiten oder vorgegebene Interfaces implementieren müssen, sind sie aber nicht wirklich unabhängig vom Persistenzaspekt. Sie sind an ein Framework gebunden und nicht so leicht testbar, wie sie es sein sollten. In der Version des Entity Frameworks, die mit Visual Studio 2010 ausgeliefert wird, können Sie auch Ihre eigenen Klassen verwenden, um das Modell zu definieren, ohne den Designer für die Codegenerierung zu verwenden. Wenn Sie den ein- [Abb. 6] Der Assistent generiert aus dem Domänenmodell ein SQL- Skript, das die passende Datenbank erzeugt. Legacy-Daten haben und auch keine Geschäftslogik wiederverwenden müssen. Wenn Sie ein brandneues Projekt starten, ist es nur eine Detailfrage, wer die Datenbank erzeugt, und die Wahl der einen oder der anderen Methode ist eine Frage der Vorliebe und der Einstellung

5 _Das Domain Model Pattern mit dem Entity Framework 2.0 umsetzen gebauten Designer benutzen, werden Sie immer Klassen erhalten, die von EntityObject ableiten, zum Beispiel so: public class Client : EntityObject : Listing 1 POCO-Klassen selbst erstellen. hält, in der Präsentationsschicht nicht verfügbar ist. Sich selbst überwachende (Self-tracking) Objekte enthalten die Logik, die nötig ist, um die Änderungen, denen sie sich unterzogen haben, zu speichern. Das heißt, dass es kein POCO-Objekt mehr ist, insofern es jetzt von dem Code verschmutzt wird, der nötig ist, um Änderungen zu verfolgen. (Am Rande: Gerade die Notwendigkeit, den Kontext dazu zu befähigen, Änderungen zu verfolgen, war der Grund dafür, dass die erste Version des Entity Frameworks keine POCO-Objekte unterstützt hat.) Sich selbst überwachende Objekte können die Grenzen der Schichten übertreten und sich anschließend wieder mit dem originalen Datenkontext verknüpfen. Der Datenkontext wird Änderungen erkennen und das modifizierte Objekt verwenden. Eine zweite Herangehensweise an sich selbst überwachende Objekte, die die POCO-Qualität nicht verletzt, bringt es mit sich, dass der Code für die Änderungsverfolgung über einen Proxy injiziert wird. Der Proxy ist eine Klasse, die von der Entität erbt und weiteren Code hinzufügt. Vom Standpunkt des Entwicklers aus ist die Verwendung eines Proxys vollständig transparent. Bei der Verwendung von Proxys ist jedoch Vorsicht geboten, wenn es darum geht, Entitäten für andere Schichten zu serialisieren: Entweder greifen Sie explizit auf Data-Transfer-Objekte zurück (DTO) und verfolgen die Änderungen manuell über eipublic class Client public int ClientID get; set; public string CompanyName get; set; public List<Order> Orders get; set; public class Order public int OrderID get; set; public DateTime OrderDate get; set; public Client Customer get; set; public List<OrderItem> Items get; set; Listing 2 Das Gerüst einer Klasse mit einem T4-Template template ClassDiagramExample processor="classdiagramexampledirectiveprocessor" requires="filename='sample.testcd'" foreach(modeltype type in this.modelroot.types) if(type is ModelClass) public class = type.name Wenn Sie im Entitätenmodell Ihre eigenen Klassen verwenden und sie persistenz - unabhängig entwerfen möchten, müssen Sie daneben ein konzeptionelles Schema der Entitäten zur Verfügung stellen, entweder abgeleitet von einer Datenbank oder von Hand erstellt. Dafür müssen Sie jedoch in Visual Studio das Code-Generation-Flag ausschalten. Als Ergebnis werden keine Dateien vom Typ xxx.designer.cs generiert, die den Code der modellierten Entitäten und darauf bezogener komplexer Typen, sofern es welche gibt, enthalten. Damit sind Sie selbst verantwortlich dafür, Code wie etwa den in Listing 1 zu schreiben. Wenn Sie Ihre POCO-Klassen manuell erzeugen, müssen Sie auch die domänenspezifische Objekt-Kontext-Klasse erstellen eine weitere Klasse, die die voreingestellte Code-Generation-Engine normalerweise für Sie erzeugt. Als Minimum bietet diese Klasse eine Collection der Entitäten und bietet Unterstützung bei der Defini - tion von Queries und wenn es darum geht, Entitäten aus der Datenbank zu beziehen und sie zurückzuspeichern. Das manuelle Erzeugen der POCO-Klasse ist aber nicht die einzige Option. Als Alternative bietet Visual Studio 2010 die T4- Templates, wobei T4 das Kürzel ist für Text Template Transformation Toolkit [1]. Über ein T4-Template steuern Sie, welchen Code der Generator für Sie erzeugt. Damit bilden T4-Templates ein Mittelding zwischen dem Code, der als Standard generiert wird, und dem vollständig manuell geschriebenen Code. Indem Sie das Template registrieren, zwingen Sie den Designer von Visual Studio 2010 dazu, diese Vorlage für die Codeerzeugung zu verwenden. Sie registrieren ein T4-Template, indem Sie im Kontextmenü auf Add New Artifact Generation Item klicken, siehe Abbildung 7. Sie erstellen ein T4-Template mithilfe einer speziellen Syntax. Listing 2 gibt Ihnen eine Vorstellung davon, wie Sie das Gerüst einer Klasse über ein T4-Template erstellen. Dieses Template erzeugt für jede Klasse, die im Entitätenmodell definiert ist, eine leeres Klassengerüst [2]. Self-tracking Entities Ein weiteres interessantes Feature des jüngsten Entity Frameworks sind Self-tracking Entities. In der alten Version des Entity Frameworks kümmert sich die Object- Context-Klasse darum, Änderungen an den verwalteten Objekten zu verfolgen. Jedes Objekt, das in eine ObjectContext-Instanz geladen wird, wird für die gesamte Lebenszeit des Kontexts auf Änderungen hin überwacht. Am Rande sei erwähnt, dass auch LINQ-to-SQL so arbeitet. Auf der einen Seite ist das gut, weil das Verfolgen der Änderungen in einem einzelnen Objekt zentralisiert ist. Auf der anderen Seite schränkt es die Mobilität der Objekte ein. Ein Beispiel: Angenommen, Sie übertragen ein Customer-Objekt in die Präsentationsschicht. Wenn das Objekt dort verändert wird, dann gehen diese Änderungen ver - loren, weil der Kontext, der das Objekt ent

6 [Abb. 7] Ein T4-Template für die Codeerzeugung registrieren. ne DTO-Adapter-Schicht, oder Sie nutzen die Möglichkeiten des Entity Frameworks und stellen sicher, dass Sie die Entität serialisieren und nicht den Proxy. Und was ist mit LINQ-to-SQL? Die Blogger von Microsofts Data-Access- Team haben es klargemacht: Microsoft spricht sich für erhebliche Investitionen in das Entity Framework aus. Es soll die empfohlene Datenzugriffslösung sein für Szenarien, bei denen mit LINQ auf relationale Daten zugegriffen werden soll. Auf der anderen Seite ist LINQ-to-SQL eine exzellente und leichtgewichtige Datenzugriffsoption mit mächtigen Erweiterungsoptionen. Sie ist leicht zu verwenden und funktioniert gut. Bislang war nicht die Rede davon, dass LINQ-to-SQL ein Auslaufmodell sein soll. Sie sollten aber nicht erwarten, dass LINQ-to- SQL künftig noch erweitert wird. Vielleicht kommt irgendwann der Tag, an dem Microsoft LINQ-to-SQL auslaufen lässt, aber dieser Tag ist noch nicht erreicht, und bis dahin wird es vielleicht auch noch einige Jahre dauern. Sicher ist, dass LINQ-to-SQL im.net Framework 4.0 und in Visual Studio 2010 enthalten sein wird. Auf kurze Sicht scheint es immer noch sinnvoll zu sein, in LINQ-to-SQL zu investieren. Es wird ein Zeitfenster von wenigen Jahren mit einem fortgesetzten Support geben. LINQ-to-SQL und das Entity Framework sind von verschiedenen Gruppen entwickelt worden und dienen unterschiedlichen Zwecken. Es gibt zwischen ihnen einige Überschneidungen, aber auch einige entscheidende Unterschiede. Es ist verständlich, dass Microsoft darauf zielt, nur ein Daten - zugriffs-framework anzubieten, und es ist auch vernünftig, dass Microsoft große Pläne für das Entity Framework hat. Microsoft wünscht sich ein umfassendes Framework, das die Erwartungen von Enterprise-Architekten und -Entwicklern erfüllen kann und das ein seriöses Domänenmodelldesign innerhalb der.net-welt ermöglicht. Auf der anderen Seite ist LINQ-to-SQL, so wie es ist, für einen großen Teil der Microsoft-Kunden einfach perfekt, nämlich für die kleinen und mittleren Unternehmen. Außerdem wurde LINQ-to-SQL in erster Linie für Webentwickler und Web - sites entwickelt. Auch große Websites benötigen nicht immer die Abstraktion und die Mächtigkeit von vollständigen O/R- Mappern wie dem Entity Framework. Viele Webentwickler wollen einfach eine schnelle und effektive Methode haben, Daten zu modellieren und Persistenz zu realisieren, ohne zusätzlichen Aufwand treiben zu müssen. Für Einsatzzwecke dieser Art ist LINQ-to-SQL optimal geeignet. Da LINQ-to-SQL vielen.net-entwicklern gute Dienste leistet, wird Microsoft LINQ-to-SQL nicht einfach fallen lassen können, ohne einen allgemein akzeptierten Ausweg, sprich einen Migrationspfad zum Entity Framework anzubieten. LINQto-SQL zu unterstützen, aber es so wie in seiner Version 1.0 zu belassen, ist auch ein gefährlicher Weg sowohl für Microsoft als auch für seine Kunden. Ich hätte am liebsten eine leichtgewichtige Version des Entity Frameworks, die das API, das Modell und die Philosophie des Entity Frameworks nutzt, aber genau das macht und anbietet, was heute LINQ-to- SQL macht und anbietet. Der Grund für diesen Wunsch: Auf diese Weise wäre Kompatibilität gewährleistet zwischen dem Basis-API (also LINQ-to-SQL oder was auch sonst immer) und neueren, künftig ent stehenden Technologien, die Microsoft noch rund um das Entity Framework erstellen wird. Wie bei so vielen anderen Architekturentscheidungen hängt die Wahl zwischen Entity Framework und LINQ-to-SQL auch vom Bauchgefühl ab. Als Daumenregel könnte man sagen: Wenn LINQ-to-SQL heute für Sie gut arbeitet und die Applikation voraussichtlich für lange Zeit unverändert bleiben wird (länger als zwei Jahre), dann können Sie es definitiv nutzen. Aber wenn die Applikation Teil eines größeren Projekts ist, bei dem die Vorteile eines echten Domänenmodells deutlich zum Tragen kommen, dann nutzen Sie auf jeden Fall das Entity Framework, auch dann, wenn heute LINQ-to-SQL noch ausreichen würde. Zusammenfassung Die Version des Entity Frameworks, die mit dem.net Framework 4.0 und Visual Studio 2010 ausgeliefert wird, ist ein großer Schritt nach vorn. Sie unterstützt POCO- Klassen im gesamten Framework, verbessert einige Programm-Features wie etwa Lazy Loading, ordnet die Objektverfolgung neu und ergänzt ein Bündel neuer Erweiterungsoptionen (Support für Stored Procedures), die unter LINQ-to-SQL einer Art Zwillingsbruder bereits verfügbar waren und von der Entwicklergemeinde lautstark gefordert wurden. Dieser Artikel hat nur an der Oberfläche des Entity Frameworks 2.0 gekratzt. Er hat sich hauptsächlich auf POCO und den neuen Code-First-Ansatz konzentriert. Dieser erlaubt es Ihnen, erst das Modell zu entwerfen und anschließend die Klassen und die Datenbanken zu generieren. Mit dem Entity Framework 2.0 ist die domänenbasierte Entwicklung, wenn nicht sogar die domänengetriebene Entwicklung erheblich leichter möglich als mit früheren Versionen. Just do it! [ml] [1] Ulrich Gronau, T4 erledigt die Fleißarbeiten, Einführung in das Text Template Transformation Toolkit, dotnetpro 8/2009, Seite 54 ff., QdnpCodeA0908T4 [2] MSDN, Domain-Specific Language Tools, Generating Artifacts By Using Text Templates, QdnpLink SL0909EF201 [3] Dino Esposito, Modelle fürs Business, Architekturmuster für die Problemdomäne, dotnetpro 12/2008, Seite 130 ff., QdnpCodeA0812DDD [4] Holger Schwichtenberg, Auf höherer Ebene, Das ADO.NET Entity Framework, dotnetpro 5/2007, Seite 94 ff., QdnpCodeA0705EntityFramework