Entity Framework 4 gegen NHibernate [geschlossen]

Es wurde viel über die erste Version von Entity Framework im Web gesprochen (auch über Stackoverflow), und es ist klar, dass dies keine gute Wahl war, wenn wir bereits eine bessere Alternative wie NHibernate haben. Ich kann jedoch keinen guten Vergleich zwischen Entity Framework 4 und NHibernate finden. Wir können sagen, dass NHibernate heute unter allen .NET-ORMs führend ist, aber wir können erwarten, dass Entity Framework 4 NHibernate von dieser Position verdrängt. Ich denke, wenn Microsoft wirklich sehr gute Funktionen in EF4 eingeführt hat, kann dies NHibernate eine gute Konkurrenz bieten, da es über eine Visual Studio-Integration verfügt, einfacher zu handhaben ist und MS-Produkte in den meisten Geschäften immer bevorzugt werden.

EF4 hat eine sofort einsatzbereite Antwort in Bezug auf die n-Tier-Entwicklung in "Self-Tracking-Entities". Niemand hat vergleichbaren Code für NHib veröffentlicht.

NHib hat viele Funktionen, die nicht als Teil von EF4 erwähnt wurden. Dazu gehört die Cache-Integration der zweiten Ebene. Es bietet außerdem eine größere Flexibilität bei der Vererbungszuordnung, eine bessere Integration in gespeicherte Prozesse / Datenbankfunktionen / benutzerdefiniertes SQL / Trigger, Unterstützung für Formeleigenschaften usw. IMO ist es im Grunde nur reifer als ein ORM.

Update: Ich habe Entity Framework seit Version 4.0 nicht mehr verwendet, daher kann meine Antwort veraltet sein. Ich verwende in meinen Projekten immer noch NH oder reines ADO .NET. Und ich möchte nicht einmal sehen, was seit 4.0 in EF neu ist, weil NH perfekt funktioniert.

Eigentlich ist es ziemlich einfach, sie zu vergleichen, wenn Sie beide verwendet haben. Es gibt einige schwerwiegende Einschränkungen bei EF4. Ich kann einige nennen, auf die ich selbst gestoßen bin:

EF4-Probleme:

• Eifriges Laden und Gestalten des Ergebnisses : Das eifrige EF4-Ladesystem (Include ("Path")) generiert falsches SQL mit Loop-JOINs, die Tausende (nicht wörtlich) langsamer für viele-zu-viele-Beziehungen ausführen als handgeschriebenes SQL (es ist) effektiv unbrauchbar).
• Materializer kann zugeordnete Entitäten nicht materialisieren : Wenn Sie glauben, dass Sie frühere Probleme durch die Bereitstellung einer eigenen SQL-Abfrage lösen können, liegen Sie falsch. EF4 kann zugeordnete Entitäten aus der JOIN SQL-Abfrage nicht materialisieren (zuordnen), sondern nur Daten aus einer Tabelle laden. dachte, alle notwendigen Daten werden in der Abfrage abgerufen, um sie zu initiieren). Dies kann durch die Verwendung des EFExtensions-Community-Add-Ons überwunden werden, aber der Code, den Sie dafür schreiben müssen, ist wirklich hässlich (ich habe es versucht).

• Self-Tracking-Entitäten: Viele sagen, dass Self-Tracking-Entitäten für die N-Tier-Entwicklung cool sind, einschließlich der Top-Antwort in diesem Thread. Obwohl ich sie noch nicht einmal ausprobiert habe, kann ich sagen, dass dies nicht der Fall ist. Jede Eingabe kann gefälscht werden. Sie können die Änderungen, die der Benutzer Ihnen sendet, nicht einfach auf die Datenbank anwenden. Warum geben Sie dem Benutzer nicht direkte Daten? Basiszugang dann? Auf jede Art und Weise, wie Sie den Datenbenutzer laden müssen, wird er von der Datenbank geändert, überprüft, ob er vorhanden ist | nicht vorhanden, Berechtigungsprüfungen durchführen usw. usw. Sie können dem Benutzer nicht vertrauen, welchen Status die Entität hat, die er an den Server sendet Sie müssen diese Entität aus der Datenbank laden und ihren Status und andere Dinge bestimmen, damit diese Informationen ebenso wie Self-Tracking-Entitäten unbrauchbar sind, es sei denn, Sie führen ein privates vertrauenswürdiges n-Tier-System für den internen Gebrauch durch. In diesem Fall könnten Sie möglicherweise einfach angeben DB-Zugriff.

• Protokollierung, Ereignisse, Integration der Geschäftslogik: EF4 ist wie eine Black Box, es macht etwas und Sie haben keine Ahnung, was es macht. Es gibt nur ein Ereignis OnSavingChanges, bei dem Sie eine Geschäftslogik einfügen können, die Sie ausführen müssen, bevor etwas mit DB passiert. Wenn Sie einige Änderungen an Geschäftsobjekten vornehmen müssen, bevor etwas passiert, müssen Sie in ObjectStateManager graben, und das ist wirklich hässlich Code kann riesig werden. Wenn Sie beispielsweise das Repository-Muster verwenden und wissen, was bei Änderungen an der Datenbank auf saubere Weise zu beachten ist, fällt es Ihnen mit EF schwer, dies zu tun.

• Erweiterbarkeit: Der gesamte EF-Code ist privat und intern. Wenn Sie etwas nicht mögen (und Sie werden nicht viel mögen, wenn Sie es mit EF ernst meinen), können Sie dies auf keine einfache Weise ändern. Ich bin mir sicher Es ist einfacher, Ihr eigenes ORM von Grund auf neu zu schreiben (ich habe es getan), als EF nach Bedarf zum Laufen zu bringen. Schauen Sie sich als Beispiel die EFExtensions-Quelle an, die auf Erweiterungsmethoden und verschiedenen "Hacks" basiert, um EF ein wenig benutzerfreundlicher zu machen, und der Code ist ziemlich hässlich (und es ist kein Fehler des Autors, wenn alles in EF privat ist, ist dies der einzige Weg, um es zu erweitern).

Ich kann weiterhin schlechte Dinge über EF schreiben und wie schmerzhaft es für mich war, etwa 20 Seiten damit zu arbeiten, und vielleicht werde ich es auch.

Was ist mit NHibernate? Es ist ein völlig anderes Level, es ist wie ein Vergleich von PHP mit C #, EF4 ist wie in der Steinzeit, es ist, als ob EF 10 Jahre hinter NHibernate im Entwicklungsfortschritt zurückliegt, und tatsächlich wurde Hibernate 2001 gestartet. Wenn Sie Freizeit haben Um Nhibernate zu lernen und einzuschalten, tun Sie es.

Hier ist das Ding. NHibernate und Entity Framework sind meiner Meinung nach wirklich für zwei verschiedene Zielgruppen gedacht. NHibernate wäre meine Wahl beim Aufbau eines Systems mit komplexen Zuordnungen, Formeln und Einschränkungen (im Grunde alles Unternehmen). Wenn ich mit einfachem Datenzugriff sofort loslegen wollte, würde ich Entity Framework oder LINQ-to-SQL verwenden. NHibernate hat kein klares "Drag-and-Drop" -Erlebnis wie EF. Beide haben ihre Stärken und Nachteile. Wenn man sie ehrlich gesagt mit Äpfeln vergleicht, kommt man nicht weiter.

Wenn Sie glauben, dass Sie Ihren Code jemals auf Mono ausführen möchten, ist NHibernate wahrscheinlich die bessere Wahl, unabhängig davon, was in den Feature-Checklisten steht ...

Bearbeiten, 13.08.2012:

Entity Framework wurde als Open-Source-Version bereitgestellt und ist ab 2.11.3 in Mono enthalten. Diese Antwort ist jetzt veraltet und sollte nicht als verlässlich angesehen werden.

http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx

Ich gehe davon aus, dass EF4.0 seit 1.0 einen langen Weg zurückgelegt hat und Nhibernate in seiner Funktionalität einholt, aber es ist noch nicht alles da.

Es ist jedoch Microsoft, das sofort einsatzbereit ist und 100% der Aufgaben erledigt, für die 95% der Anwendungen erforderlich sind. NHibernate macht jedoch seit Jahren dasselbe. Die kommende Version 5.0 oder 6.0 kann NHibernate einholen oder sogar übertreffen.

Hier ist mein Rat - wenn Sie Zeit haben, beides zu lernen, dann tun Sie es. Es gibt mehrere Gründe, sich für einen zu entscheiden. Wenn Sie Code für ein Unternehmen schreiben, ist es realistisch zu erwarten, dass Sie fähige Mitarbeiter sind, die mit EF vertraut sind, wie es in allen Büchern steht und was Kinder im College lernen. Wenn EF Ihre Anforderungen erfüllt (denken Sie lange und gründlich darüber nach, bevor Sie nur Ja sagen), dann ist es vorerst eine vollkommen gute Lösung, und in einigen Jahren kann es NHibernate übertreffen (ok, höchstwahrscheinlich).

NHibernate ist ein sehr ausgereiftes Produkt mit einigen Jahren Erfahrung bei EF und wird höchstwahrscheinlich alles tun, was Sie jemals tun möchten, und noch viel mehr. Es ist seit einiger Zeit das beste ORM und wird von vielen Leuten verwendet.

Ich denke, dass die Tatsache, dass EF 4 POCO verwenden kann und verzögertes Laden verzögert wird, sehr groß sein wird. Ich konnte definitiv sehen, dass es mit der neuen Version an Fahrt gewinnt.

Es gibt einen offensichtlichen Trend, die EF-Popularität gegenüber NHibernate zu erhöhen, siehe Bild.

Meine 2 Cent: Wir verwenden ef auf unserem Desktop-Client für Cahing usw. - keine Hi-Loads. Eine NHib auf der Serverseite - mit zustandslosen Sitzungen, Hilo-ID-Generierung und Batches. Is ist ziemlich schnell beim Einfügen von 3k + Nachrichten in db pro Sekunde. Außerdem ist es sehr flexibel und unterstützt viele DBS, was für unser Produkt entscheidend ist.

Die direkte Zuordnung zu gespeicherten Prozeduren mit einer Kombination von Linq für eine logische Ebene scheint der einfachste Ansatz zu sein. Keine XML. Generieren Sie SQL nur für interessante Abfragen, die weniger häufig verwendet werden oder für gespeicherte Prozeduren nicht geeignet sind.

Objekte werden über Standard-SPs geladen und gespeichert. Dieser Ansatz ermöglicht die Verwendung von zwei SQL-Anmeldungen. Eine für den Klassenzugriff über SPs (Nur-Ausführungsberechtigungen) und eine für ein logisches Linq-Modul, das den direkten Tabellenzugriff ermöglicht.

Die Wahl zwischen ORMs nach Beliebtheit ist nicht das Beste. Ich habe in den letzten 2 Jahren versucht, zu EF zu wechseln, und alles was ich sagen kann ist, warum zum Teufel versuche ich es immer noch?

ATM Mein Standpunkt zu EF ist: "Es ist für wirklich kleine, ziemlich kleine Bit-Systeme mit nicht mehr als 3 Tabellen mit weniger als 1 Beziehung gemacht (0 ist besser)."

Und warum denke ich so? 1. Versuchen Sie, ein nicht verbundenes Diagramm zu aktualisieren und den Kratzer Ihres Modells zu sehen.

1. Wenn Sie versuchen, TPH mit tief vererbten Bäumen zu erstellen, werden Sie feststellen, dass Sie an eine einzelne Hierarchie gebunden sind, da sonst das System kaputt geht.

2. Versuchen Sie, umständlichere Abfragen zu stellen, und beobachten Sie, wie das gesamte System den Stapel auffrisst: D ... Überläufe treten sehr häufig auf.

3. Map XML-Datentypen basieren auf Erweiterungen oder den am meisten "gehassten" NotMapped-Eigenschaften ... und es ist noch schlimmer.

4. Versuchen Sie, SQL-Abfragen in Linq zu mischen, um genauere Abfragen zu erhalten, und Sie werden die Mauer brechen lol.

5. Und das Letzte und Wichtigste ist, dass EF keine Eigenschaftsformel unterstützt („eine großartige Ressource, die NH für ältere Datenbanken hat“) und keine komplexen Typzuordnungen für dieselbe Tabelle und verwandte Tabellen unterstützt.

Das ist mein 10cc.