Nun, ich habe gerade ein komplettes System in EF implementiert, es war meine erste echte Erfahrung mit EF in einer Produktionsumgebung. Die App läuft jetzt seit etwa 45 Tagen mit 100 Benutzern, die sie täglich ohne Probleme nutzen.
Ich denke, das Wichtigste ist, dass man sein Denken ändern muss. Wenn Sie wie ein ORM für relationale Datenbanken denken, dann haben Sie bereits die falsche Denkweise. Sie müssen in partiellen Methoden, Objekten und Erweiterungen denken. Sobald man diese grundlegende Denkweise verinnerlicht hat, fangen die Dinge an zu fließen (und man schreibt eine Menge Code um, als man anfing).
Hilfe zu bekommen ist schwer
Der andere frustrierende Teil von EF ist, dass überall, wo man um Hilfe bittet, lauter L2S-Bonzen sitzen, die meinen, sie wüssten schon alles, was man tun muss, und immer wieder versuchen, einem zu sagen, man solle es sein lassen und einfach L2S benutzen... Wenn ich danach gefragt hätte, wie man das in L2S macht, dann wäre ihre Meinung vielleicht gültig...
EF funktioniert gut
Die grundlegende Fähigkeit, Objekte zu erzeugen, die man dann durch Teilmethoden erweitern kann, funktioniert gut. In der Anfangsphase war ich ziemlich frustriert, weil ich immer wieder versucht habe, die Dinge so hinzubekommen, wie ich es in einem SQLCommand tun würde. Wenn man erst einmal erkannt hat, dass man eher an die Anforderungen der Geschäftslogik als an die Funktionsweise von SQL denken kann, kann man viel mehr erreichen.
Ich habe zum Beispiel immer wieder versucht, Joins zu erstellen, um eine Liste von Dingen zu erhalten, die durch einen bestimmten FK für verschiedene Aufgaben miteinander verbunden sind. Als ich schließlich herausfand, dass ich die gesamte Where-Klausel an die FK übergeben kann und diese herausfindet, wie sie die Daten schnell zu mir zurückbringt, war der Code tatsächlich viel schneller.
Enthält Stinkstoff
Die Include-Syntax kommt mir allerdings wie ein Hack vor. Die Verwendung von .Include("Tabellenname.DetailTable") ist unschön. Vielleicht bin ich nur von Intellisense verwöhnt, aber ich hasse diese Syntax.
Last auf Anfrage
Master-Detail-Lasten sind auch ein bisschen hässlich. Wenn Sie sie nicht einbeziehen wollen, können Sie immer ihre Referenz nehmen und sehen, ob sie .IsLoaded und dann .Load aufrufen. Aber warum? Kann das Objekt das nicht für mich tun? Ich habe schließlich eine Erweiterungsmethode für meine Objekte implementiert, die, wenn ich versuche, eine Detailklasse zu laden, die nicht geladen ist, diese bei Bedarf lädt. Mir scheint, das hätte eingebaut werden müssen.
Hinweis: Das im obigen Beitrag erwähnte detaillierte Laden eines gefilterten Datensatzes ist nicht kompliziert, aber auch nicht offensichtlich. Sie können mit Lambda-Ausdrücken filtern.
Wollen Sie das Projekt JEMALS verschieben?
Hier ist der Hauptgrund: Keine Bindung an einen bestimmten Anbieter. Wenn Sie diesen Code jemals in eine andere Datenbank übernehmen wollen, können Sie das mit Linq2SQL NICHT tun. Es gibt kein Anbietermodell. Sie haben vielleicht die Möglichkeit, ein EF-System zu einem anderen Anbieter zu verschieben. In meinem Fall läuft das gleiche Projekt auf SQL Server und VistaDB EF (Alpha) ohne Codeänderungen. Ich kann es also per Xcopy bereitstellen oder mich zur Laufzeit mit einem Server meiner Wahl verbinden.
