Ein konzeptionelles Problem des Entity Frameworks ist das explizite Entity Data Model (EDM). Klar, irgendwo muss beschrieben werden, was wie zu mappen ist. Aber das explizite EDM ist redundant: Entitätsklassen müssen zum einen entwickelt und zum anderen im EDM, genauer gesagt im CSDL-Teil, beschrieben werden. Dasselbe gilt für DB-Strukturen und die Beschreibung im SSDL-Teil des EDM. Wenn sich irgendwo etwas ändert, muss das an den anderen Stellen nachgezogen werden. Das ist aber nicht das einzige Problem:
1. Ab einer gewissen Anzahl an Entitäten wird die graphische Darstellung des EDM unübersichtlich. Normalerweise würde man nun das Modell auf verschiedene Submodelle aufteilen, aber das ist nicht ohne weiteres möglich, zumal man nicht auf Tabellen in anderen Modellen referenzieren kann.
2. Das Modell kann nicht einfach modularisiert werden. Der Grund dafür ist derselbe, wie beim letzten Punkt: Man kann Modelle nicht sinnvoll aufteilen.
3. Kommen wir zum letzten Punkt: Wechsel der Datenbank. Dies ist ja eines der großen Versprechen von O/R-Mappern. Möchte man das eingesetzte DBMS wechseln, muss man für das neue DBMS ein erneutes SSDL generieren lassen und dieses gemeinsam mit den existierenden MDL-Teil und CSDL-Teil verwenden.
Bei (N)Hibernate gibt es diese Probleme eigentlich nicht. Der Grund dafür ist, dass lediglich die Mapping-Aspekte zu beschreiben sind – und das auf eine, im Vergleich zu den XML-Untiefen des EDM, ziemlich übersichtliche Art. Alles andere leitet das Framework aus den bestehenden Klassen ab.
Glücklicherweise ist dies seit Entity Framework 4.1 mit dem Code-First-Ansatz nun auch möglich. Dieser suggeriert zwar, dass man zuerst die Entitäten modellieren muss und dann daraus eine Datenbank zu erstellen ist, aber dank der Möglichkeit von Codegenerierung ist dies nicht der Fall. So bietet zum Beispiel die Entity Framework Power Tools CTP1, welche über den Extension Manager von VS 2010 bezogen werden können, diese Möglichkeit.
Feed
Twitter
XING
