it-swarm-eu.dev

Was sind einige Argumente GEGEN die Verwendung von EntityFramework?

Die Anwendung, die ich derzeit erstelle, verwendet gespeicherte Prozeduren und handgefertigte Klassenmodelle, um Datenbankobjekte darzustellen. Einige Leute haben vorgeschlagen, Entity Framework zu verwenden, und ich denke darüber nach, darauf umzusteigen, da ich noch nicht so weit im Projekt bin. Mein Problem ist, ich habe das Gefühl, dass die Leute, die für EF streiten, mir nur die gute Seite der Dinge erzählen, nicht die schlechte Seite :)

Meine Hauptanliegen sind:

  • Wir möchten eine clientseitige Validierung mit DataAnnotations, und es scheint, als müsste ich die clientseitigen Modelle sowieso erstellen, sodass ich nicht sicher bin, ob EF so viel Codierungszeit sparen würde
  • Wir möchten die Klassen beim Überqueren des Netzwerks so klein wie möglich halten, und ich habe gelesen, dass die Verwendung von EF häufig zusätzliche Daten enthält, die nicht benötigt werden
  • Wir haben eine komplexe Datenbankschicht, die mehrere Datenbanken umfasst, und ich bin nicht sicher, ob EF damit umgehen kann. Wir haben eine gemeinsame Datenbank mit Dingen wie Benutzern, Statuscodes, Typen usw. und mehreren Instanzen unserer Hauptdatenbanken für verschiedene Instanzen der Anwendung. SELECT-Abfragen können und werden alle Instanzen der Datenbanken abfragen. Benutzer können jedoch nur Objekte ändern, die sich in der Datenbank befinden, an der sie gerade arbeiten. Sie können die Datenbank wechseln, ohne die Anwendung neu zu laden.
  • Objektmodi sind sehr komplex und es sind oft einige Verknüpfungen beteiligt

Argumente für EF sind:

  • Parallelität. Ich müsste nicht vor jedem Speichern prüfen, ob der Datensatz aktualisiert wurde
  • Codegenerierung. EF kann Teilklassenmodelle und POCOs für mich generieren, aber ich bin nicht sicher, dass dies mir wirklich so viel Zeit sparen würde, da ich denke, dass wir noch die clientseitigen Modelle für die Validierung und einige benutzerdefinierte Analysemethoden erstellen müssten.
  • Entwicklungsgeschwindigkeit, da wir nicht die gespeicherten CRUD-Prozeduren für jedes Datenbankobjekt erstellen müssten

Unsere aktuelle Architektur besteht aus einem WPF-Service, der Datenbankaufrufe über parametrisierte gespeicherte Prozeduren, POCO-Objekte, die zum/vom WCF-Service und dem WPF-Client gehen, und dem WPF-Desktop-Client selbst verarbeitet, der POCOs zum Zweck der Validierung und in Klassenmodelle umwandelt Datenbindung.

Meine Frage ist also, ist EF dafür richtig? Gibt es Fallstricke bei EF, die mir nicht bekannt sind?

31
Rachel

Ich habe kürzlich Entity Framework evaluiert und der beste Ort, den ich für Probleme und fehlende Funktionen gefunden habe, war: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Die Artikel mit den meisten Stimmen:

  1. Unterstützung für Aufzählungen. Dieser ist ziemlich groß, aber es gibt derzeit einige Problemumgehungen
  2. Verbesserte SQL-Generierung. Geschwindigkeit ist besonders für Anwendungen auf Unternehmensebene sehr wichtig, aber mit EF4 scheint sie sich stark verbessert zu haben
  3. Unterstützung für mehrere Datenbanken. Voraussetzung für jede große Anwendung.

Es gibt viele weitere Probleme in der User Voice-Liste.

Nebenbei bemerkt, ich freue mich sehr über die bevorstehende Veröffentlichung von EF 4.1, die den Code-First-Ansatz enthalten wird ... http://blogs.msdn.com/b/adonet/archive/2011/03/15 /ef-4-1-release-candidate-available.aspx

Dies kann mich tatsächlich dazu bringen, EF in einer Produktionsanwendung zu testen.

7
Mag20

Das Ausführen von Branch-per-Bug/Feature mit EF kann beim Zusammenführen bemerkenswert schmerzhaft sein. Stellen Sie sich vor, zwei Zweige A und B nehmen Änderungen an der Datenbank vor (was wahrscheinlich in den frühen Phasen eines neuen Projekts häufig vorkommt).

Sie führen alle "normalen" Dateien zusammen - CS-Dateien usw. Und dann ist es Zeit, Model.edmx zusammenzuführen. Und plötzlich führen Sie nicht nur die logischen Zuordnungen zwischen Ihrem Objektmodell und der Datenbank zusammen, sondern auch die Positionen der Tabellen im Entitätsdiagramm.

Das Zusammenführen von Model.edmx ist so schmerzhaft, dass wir einen ziemlich bösen Weg eingeschlagen haben, der funktioniert:

  • Wählen Sie während der Zusammenführung einfach alle Zusammenführungen von einem übergeordneten Element aus. Was nicht wichtig ist; Sie werden die Datei sowieso bald anstoßen:
  • Setzen Sie Model.edmx auf eines der übergeordneten Elemente zurück.
  • Migrieren Sie Ihre Datenbank in den neuen zusammengeführten Status.
  • Öffnen Sie die Datei Model.edmx und klicken Sie auf "Modell aus Datenbank aktualisieren".
  • Benennen Sie alle während der Zusammenführung gerösteten Navigationseigenschaften um.
7
Frank Shearar

EF hat noch ein paar andere Vorteile, die Sie vermissen:

  • Sie können Entity-Span-Tabellen haben
  • Sie können eine Tabelle in viele Arten von Entitäten aufteilen
  • Sie können die Entitäten aus der Datenbank generieren (d. H. Datenbank als Master-Ansatz).
  • Sie können die Datenbank aus Entitäten generieren (d. H. Code als Master-Ansatz).
  • LINQ-Abfragen werden in SQL-Abfragen übersetzt, wodurch ihre Leistung verbessert wird.

Die Nachteile (insbesondere wenn Sie die Validierung verwenden):

  • Sie müssen ein [MetadataClass] -Attribut erstellen, das auf eine andere Klasse verweist, die die Eigenschaften aufweist, die Sie mit den entsprechenden Validierungsattributen validieren möchten. Alle Eigenschaften sind object -Typen, daher können nur die Metadaten gelesen werden. Immer noch viel extra inaktiver Code.
  • Die Verwendung von EntityFramework ist ein anderes Konzept als die Art und Weise, wie etwas wie NHibernate (und die übergeordnete Version Java Version)) funktioniert. EntityFramework funktioniert am besten in einem angehängten Modus, in dem Die Objekte verwenden zu jeder Zeit eine Live-Verbindung. NHibernate und ähnliche ORM-Tools funktionieren am besten im Modus getrennt, in dem die Verbindung nur beim Laden/Speichern von Daten verwendet wird.

Das sind die beiden größten Beschwerden, die ich habe. Es gibt eine Reihe von Vorteilen, aber Sie können möglicherweise dieselben Vorteile von NHibernate erhalten. Wenn EntityFramework auf dem Tisch liegt, lassen Sie das Team auch NHibernate überprüfen und schnell nach den Vor- und Nachteilen für Ihr Projekt suchen.

Das Problem mit der Metadatenklasse bereitet Kopfschmerzen, aber zum Glück habe ich nur so viele Entitäten, die Validierungs-Tags benötigen.

Das Fehlen eines echten getrennten Modus für Ihre Objekte schränkt die Möglichkeiten in einer Webumgebung ein. Der angehängte Modus ist besser für Desktop-Anwendungen geeignet, aus denen eine Reihe von Microsoft-Innovationen hervorgegangen sind. Der freistehende Modus ist möglich, aber sehr schmerzhaft. In diesem Fall ist es am besten, ein alternatives Tool zu verwenden.

5
Berin Loritsch

Eine Sache, in der Microsoft nicht sehr gut ist, ist rückwärts vergleichbarkeitkompatibilität, insbesondere bei neuen Technologien

Insbesondere EF1 (.net 3.5) unterscheidet sich stark von EF4 (.net 4.0) - dasselbe kann für die nächste Version auftreten.

Ich würde eine Weile warten und sehen, wie die Technologie reift.

In der Zwischenzeit sollten Sie nHibernate verwenden - es ist nicht gleichwertig, aber es ist ausgereift und wird häufig verwendet.

2
Ophir Yoktan
  • Einfach ... das Domänenmodell ist selten eine Replik des relationalen Modells in Ihrer Datenbank. Einige Tabellen einer Klasse zuzuordnen und über den Draht zu werfen, ist also einfach nur Faulheit. Tabellen können lokal einem Objekt zugeordnet werden, obwohl die Datenbank aus 3 verschiedenen Tabellen besteht. Entwerfen Sie die Datenbank intelligent.
  • 2. Dieses EF-Zeug kann bestimmte Abfragen nicht generieren und Sie müssen sie trotzdem schreiben.
  • 3. Das Domain-Modell wird nicht direkt auf Dienste abgebildet. Man möchte nur den minimalsten Datensatz als DTOs über das Kabel übertragen. Insbesondere, wenn es mit mobilen Apps kommunizieren soll.
  • 5. Testfähigkeit ... Es können nicht genügend detaillierte Tests erstellt werden, die eine ausreichende Regression gegen Codeänderungen bieten ... alles zu einfach
    brechen ...

Ich könnte eine 10-seitige Diatribe schreiben. Aber wenn Sie nur eine Wegwerf-App für Firma X schreiben ... wen interessiert das dann? Aber wenn Sie ein Softwareprodukt entwickeln ... müssen Sie viel analer sein

1
user104468

Überprüfen Sie dies: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Die Hauptpunkte sind:

  • Mangel an faulem Laden
  • Mangel an Beharrlichkeit Unwissenheit
  • Das zum Speichern des Entitätsmodells verwendete Dateiformat enthält sowohl Visualisierungselemente als auch das Entitätsmodell selbst verursacht Zusammenführungsprobleme in der Teamumgebung.

Beachten Sie, dass der obige Link über EF1 spricht.

Auch dieser Link: http://ormeter.net/ zeigt, dass EF im Vergleich zu anderen ORMs in Bezug auf Leistung und LINQ-Unterstützung nicht die beste ist.

0
M.Sameer