Entity Framework 4 gegen NHibernate [geschlossen]

114

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.

Deependra Solanky
quelle
31
Ich möchte ein Update dieses Vergleichs. Ist seit '09 viel passiert?
Phil

Antworten:

66

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.

John Rayner
quelle
13
+1 Du hast recht. NH ist gerade ausgereift. EF wird bis Ende des Jahres aufholen. Version 4.0 hat bereits einen dramatischen Auftritt. Geben Sie ihm etwas Zeit und es wird bis Mitte 2011 kugelsicher sein.
15
-1 Für "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." Es gibt ISession.Merge in NHibernate, das aus vielen Gründen viel besser ist als Self-Tracking-Entitäten für die N-Tier-Entwicklung.
Alex Burtsev
12
@Alex - Inwiefern ist NHibernate eine "out of the box" -Lösung? Nur um klarzustellen; "Out of the Box" bedeutet, dass es mit einer Vanille-Installation von Visual Studio funktioniert. Das ist genau dort eine ungerechtfertigte -1.
Doktor Jones
9
@DoctaJonez - So wie ich es gelesen habe, bestritt Alex die Idee, dass NH nichts Vergleichbares zu Self-Tracking-Entitäten hat, nicht den Teil, dass es "out of the box" ist.
Jerph
2
Eigentlich habe ich festgestellt, dass EF4 eine flexiblere Vererbungszuordnung hat. Sie können beispielsweise 2 Tabellen (TPT) als Basisklasse + Klasse der Klasse 1 verwenden und der Tabelle der Ebene 1 einen Diskriminator hinzufügen, um die Aufteilung in Klassen der Ebene 2 zu ermöglichen. In NH kann der Diskriminator nur für die Basisklasse definiert werden.
Danny Varod
37

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.

Alex Burtsev
quelle
1
EF wurde unter der Apache 2-Lizenz veröffentlicht, die bei der Erweiterbarkeit helfen soll.
CMircea
@MirceaChirea Das sind großartige Neuigkeiten, ich habe das nicht erwartet, jetzt im EF-Quellcode zu surfen, ziemlich interessante Lektüre.
Alex Burtsev
2
-1 für mehrere Aussagen, denen "Ich habe das nicht benutzt, aber ich spreche trotzdem" vorangestellt ist.
Kyeotic
@ Tyrsius Meine Antwort wurde vor fast 3 Jahren geschrieben. Ich habe EF schon lange nicht mehr verwendet. Einige Dinge könnten sich verbessern. Sie können meine Antwort bearbeiten, um sie auf den aktuellen EF-Status zu aktualisieren.
Alex Burtsev
2
Sie geben zu, dass Sie noch nie Self-Tracking-Entitäten verwendet haben, entlassen sie jedoch. Wie wäre es, wenn Sie nur mit dem sprechen, was Sie wissen, und die unwissenden Vermutungen weglassen, zumal der gesamte Absatz ziemlich falsch ist.
Tom Halladay
25

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.

zowens
quelle
13
Haben Sie ActiveWriter ausprobiert? Entity Framework ist absolut auf den Unternehmensbereich ausgerichtet. Ich bin mit den meisten Ihrer Aussagen nicht einverstanden.
Michael Maddox
1
Stimmen Sie nicht zu, was Sie wollen, aber die Tatsache, dass NHibernate schon länger besteht, wird von Unternehmen NICHT übersehen.
Zowens
21
-1 Dies ist kein guter Vergleich zwischen NHibernate und Entity Framework. Es ist bestenfalls unaufrichtig, die beiden zu vergleichen, indem EF mit LINQ zu SQL zusammengefasst wird, nur b / c, das Drag & Drop hat. Was genau kann NHibernate in Bezug auf die Komplexität, was EF 4 nicht kann?
Kevin Babcock
14
Second Level Caching, ihre Abfragen sind HOCH optimiert, NH zwingt Sie, das UnitOfWork-Muster zu verwenden, und Zuordnungen werden nicht in einer Datei gestaut. Meine Meinung (aus Erfahrung) ist, dass NHibernate performanter ist. Ich stimme dem nicht zu, aber ich habe gesagt, das war meine Meinung. Mein Punkt in meiner Antwort ist immer noch gültig, sie haben beide ihre Stärken und Schwächen. Niemand kann das leugnen.
Zowens
2
@ MakerOfThings7 das ist erbärmlich ... diese ganze Frage ist subjektiv. Wach auf ...
Zowens
23

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

Joel Mueller
quelle
In der Tat heißt es unter mono-project.com/Compatibility "EntityFrameworks - Nicht verfügbar." Und es sieht so aus, als ob niemand daran interessiert ist, es zu implementieren. Zumindest für ein paar Jahre ist es NHibernate oder nichts.
Benutzer276648
12

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.

Dean
quelle
10

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.

YeahStu
quelle
7
Vergessen Sie nicht die LINQ-Unterstützung. NHibernate ist immer noch nicht gut darin.
Arnis Lapsa
1
@Arnis, können Sie Links zur Untermauerung dieser Meinung bereitstellen?
Michael Maddox
2
@Michael Dies wird deutlich, wenn Sie Ayandes Blog-Beiträge zu diesem Thema durchsehen. LINQ to NH basiert derzeit auf der Kriterien-API. Die Kriterien-API erlaubt einige der komplexeren Abfragefunktionen, die HQL kann, nicht. In der nächsten Version von LINQ to NH wird HQL anstelle der Kriterien-API verwendet.
Zowens
5

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

NHibernate vs Entity Framework

Tomas Kubes
quelle
Was ist der Sinn Ihrer Antwort? yourlogicalfallacyis.com/bandwagon
Răzvan Flavius ​​Panda
Entsprechend dem Trend beginnen die Leute im Laufe der Zeit, EntityFramework häufiger zu googeln. Und sie können gute Gründe dafür haben. Vielleicht wurde es besser.
Tomas Kubes
Dies könnte der Fall sein, es könnte auch der Fall sein, dass standardmäßig vorgeschlagen wird, von MS verwendet zu werden. Auch das Werkzeug für EF ist ziemlich gut.
Răzvan Flavius ​​Panda
4

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.

Aleksei Anufriev
quelle
3

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.

Andrew
quelle
1

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.

Moisés Gonçalves
quelle