Sonntag, 12. Juli 2009

Disaster Entity Framework

Der Titel sagt schon das meiste aus. Ich hatte vor kurzem die Ehre in einem Projekt das Entity Framework kurz kennen zu lernen. Die Betonung liegt auf kurz. Wir haben uns nämlich in Kürze dafür entschieden das Entitiy Framework wieder auszubauen. Ich habe das Entity Framework nie wirklich für einen Enterprise-tauglichen O/R Mapper gehalten, ebenso linq-to-sql nicht. Aber so eine Art verbessertes DataSet, für schnelle, überschaubare Applikationen habe ich schon erwartet. Ja, vielleicht habe ich sogar erwartet, dass ich ein kleines, leichtgewichtiges Domain Model damit bauen kann.
Leider egal was, aus meiner Sicht kann das Entity Framework nicht für viel mehr gebraucht werden als ein Drag & Drop sample. Zumindest beim jetzigen Stand der Entwicklung.

Hier einige Punkte die uns ganz besonders gestört haben:

  • Change Tracking wird zwar geführt, allerdings ist es unglaublich schwierig an die veränderten Objekte zu kommen. Der Object Context gibt nämlich per Default immer nur das zurück was in der Datenbank ist. Simple OK/Cancel Szenarien oder Offline Caching werden also im Nu zu einem Workaround.
  • Kein Forward Engineering der Datenbank. Alles muss zuerst in der Datenbank erstellt werden und anschliessend kann das Modell aktualisiert werden.
  • Keine Update-Scripts für bestehende Datenbanken. Nicht so wie ich das z.B. von einem Telerik Open Access kenne. Update-Scripts für bestehende Kundendatenbanken bei Schemaänderungen müssen manuell vorgenommen werden.
Das ist nur ein Ausschnitt der Unannehmlichkeiten mit dem Entity Framework, aber es sind wohl die grössten, zumindest für mein letztes Projekt. Klar man kann das meiste umgehen, vor allem mit einigen Workarounds. Aber das ist nicht das was ich von einer neuen O/R Mapping Technologie erwarte. O/R Mapping Tools gibts seit geraumer Zeit einige und man könnte doch erwarten, dass man da zumindest etwas abguckt.
Übrigens sind die Unterschiede zwischen Linq-To-SQL und EF erschreckend klein - zumindest für den Praxisgebrauch. Linq-To-SQL unterstützt aber immerhin Forward Engineering.

Meine Empfehlung für Enterprise-Projekte und Datenzugriff: Lasst die Finger von EF und Linq-To-SQL. Jetzt verwenden wir für diese Projekt wieder gute alte DataSets.