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.
Ü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.
2 Kommentare:
Ich kann diese Erfahrungen grossteils nachvollziehen.
Ich habe unter http://www.entityframework.de eine ausführliche Arbeit zu O/R-Mapper allgemein und zum Entity Framework im speziellen zum Download bereit gestellt.
Im Theorieteil geht es vor allem darum welche Funktionalität ein O/R-Mapper erfüllen soll.
Der Praxisteil vergleicht das Entity Framework mit NHibernate und dem kommerziellen Genome von TechTalk.
NHibernate und Genome dagegen sind beide hervorragende Produkte mit denen man problemlos skalierbare Enterprise-Applikationen bauen kann.
Hallo Günter,
Ich habe eben mal in deine Arbeit geschaut. Dein Überblick ist ziemlich treffend - hatte gerade ein dejà vu. Schade, ich hätte mehr von MS erwartet - nein wohl eher erhofft.
Kommentar veröffentlichen