Code-first vs. Model/Database-first [geschlossen]

StackOverflow https://stackoverflow.com/questions/5446316

Frage

Welche Vor- und Nachteile hat die Verwendung von Entity Framework 4.1 Code-first gegenüber Model/Database-first mit EDMX-Diagramm?

Ich versuche, alle Ansätze zum Aufbau einer Datenzugriffsschicht mithilfe von EF 4.1 vollständig zu verstehen.Ich verwende das Repository-Muster und IoC.

Ich weiß, dass ich den Code-First-Ansatz verwenden kann:Definiere meine Entitäten und meinen Kontext von Hand und verwende sie ModelBuilder um das Schema zu verfeinern.

Ich kann auch eine erstellen EDMX Diagramm und wählen Sie einen Codegenerierungsschritt aus, der T4-Vorlagen verwendet, um dasselbe zu generieren POCO Klassen.

In beiden Fällen endete ich mit POCO Objekt, das sind ORM Agnostiker und Kontext, der sich daraus ergibt DbContext.

Database-First scheint am attraktivsten zu sein, da ich die Datenbank im Enterprise Manager entwerfen, das Modell schnell synchronisieren und mit dem Designer optimieren kann.

Was ist also der Unterschied zwischen diesen beiden Ansätzen?Geht es nur um die Präferenz VS2010 gegenüber Enterprise Manager?

War es hilfreich?

Lösung

Ich denke, die Unterschiede sind:

Zuerst codieren

  • Sehr beliebt, da Hardcore-Programmierer keinerlei Designer mögen und das Definieren von Zuordnungen in EDMX-XML zu komplex ist.
  • Volle Kontrolle über den Code (kein automatisch generierter Code, der schwer zu ändern ist).
  • Die allgemeine Erwartung ist, dass Sie sich nicht um DB kümmern.DB ist nur ein Speicher ohne Logik.EF übernimmt die Erstellung und Sie möchten nicht wissen, wie es die Aufgabe erledigt.
  • Manuelle Änderungen an der Datenbank gehen höchstwahrscheinlich verloren, da Ihr Code die Datenbank definiert.

Zuerst die Datenbank

  • Sehr beliebt, wenn Sie eine Datenbank haben, die von Datenbankadministratoren entworfen, separat entwickelt wurde oder wenn Sie über eine bestehende Datenbank verfügen.
  • Sie lassen EF Entitäten für Sie erstellen und generieren nach der Änderung der Zuordnung POCO-Entitäten.
  • Wenn Sie zusätzliche Funktionen in POCO-Entitäten wünschen, müssen Sie entweder die Vorlage T4 ändern oder Teilklassen verwenden.
  • Manuelle Änderungen an der Datenbank sind möglich, da die Datenbank Ihr Domänenmodell definiert.Sie können das Modell jederzeit aus der Datenbank aktualisieren (diese Funktion funktioniert recht gut).
  • Ich verwende dies oft zusammen mit VS-Datenbankprojekten (nur Premium- und Ultimate-Version).

Modellieren Sie zuerst

  • Meiner Meinung nach beliebt, wenn Sie Designer-Fan sind (= Sie schreiben nicht gerne Code oder SQL).
  • Sie „zeichnen“ Ihr Modell und lassen den Workflow Ihr Datenbankskript und die T4-Vorlage Ihre POCO-Entitäten generieren.Sie verlieren einen Teil der Kontrolle über Ihre Entitäten und Ihre Datenbank, sind aber bei kleinen, einfachen Projekten sehr produktiv.
  • Wenn Sie zusätzliche Funktionen in POCO-Entitäten wünschen, müssen Sie entweder die Vorlage T4 ändern oder Teilklassen verwenden.
  • Manuelle Änderungen an der Datenbank gehen höchstwahrscheinlich verloren, da Ihr Modell die Datenbank definiert.Dies funktioniert besser, wenn Sie das Power Pack zur Datenbankgenerierung installiert haben.Damit können Sie das Datenbankschema aktualisieren (anstatt es neu zu erstellen) oder Datenbankprojekte in VS aktualisieren.

Ich gehe davon aus, dass es im Fall von EF 4.1 mehrere andere Funktionen im Zusammenhang mit Code First vs.Zuerst Modell/Datenbank.Die in Code First verwendete Fluent-API bietet nicht alle Funktionen von EDMX.Ich gehe davon aus, dass Funktionen wie die Zuordnung gespeicherter Prozeduren, Abfrageansichten, das Definieren von Ansichten usw.funktioniert, wenn zuerst Modell/Datenbank verwendet wird und DbContext (Ich habe es noch nicht ausprobiert), aber sie sind nicht zuerst im Code enthalten.

Andere Tipps

Ich denke, dieser einfache „Entscheidungsbaum“ von Julie Lerman, der Autorin von „Programming Entity Framework“, sollte dabei helfen, die Entscheidung sicherer zu treffen:

a decision tree to help choosing different approaches with EF

Mehr Info Hier.

„Datenbank zuerst“ und „Modell zuerst“ weisen keine wirklichen Unterschiede auf.Der generierte Code ist derselbe und Sie können diese Ansätze kombinieren.Sie können beispielsweise eine Datenbank mit dem Designer erstellen, die Datenbank dann mit einem SQL-Skript ändern und Ihr Modell aktualisieren.

Wenn Sie zuerst Code verwenden, können Sie das Modell nicht ändern, ohne die Datenbank neu zu erstellen und alle Daten zu verlieren.Meiner Meinung nach ist diese Einschränkung sehr streng und erlaubt nicht, Code zuerst in der Produktion zu verwenden.Im Moment ist es nicht wirklich nutzbar.

Der zweite kleine Nachteil von Code First besteht darin, dass der Modellersteller Berechtigungen für die Masterdatenbank benötigt.Dies hat keine Auswirkungen auf Sie, wenn Sie eine SQL Server Compact-Datenbank verwenden oder den Datenbankserver steuern.

Der Vorteil von Code First ist ein sehr sauberer und einfacher Code.Sie haben die volle Kontrolle über diesen Code und können ihn problemlos ändern und als Ansichtsmodell verwenden.

Ich kann empfehlen, den Code-First-Ansatz zu verwenden, wenn Sie einfache eigenständige Anwendungen ohne Versionierung erstellen und „Model\Database First“ in Projekten verwenden, die in der Produktion geändert werden müssen.

Zitieren der relevanten Teile aus http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 Gründe, Code First Design mit Entity Framework zu verwenden

1) Weniger Cruft, weniger Blähungen

Die Verwendung einer vorhandenen Datenbank zum Generieren einer .edmx -Modelldatei und der zugehörigen Codemodelle führt zu einem riesigen Stapel von automatisch generiertem Code.Sie werden diese generierten Dateien niemals berühren, damit Sie etwas brechen, oder Ihre Änderungen werden in der nächsten Generation überschrieben.Der Kontext und der Initialisierer sind auch in diesem Chaos zusammengeklemmt.Wenn Sie Ihren generierten Modellen Funktionen hinzufügen müssen, z.Dies ist eine Voraussetzung für fast jedes Modell und Sie haben eine Erweiterung für alles.

Mit Code First werden Ihre handcodierten Modelle zu Ihrer Datenbank.Die genauen Dateien, die Sie erstellen, generieren das Datenbankdesign.Es gibt keine zusätzlichen Dateien und es müssen keine Klassenerweiterung erstellt werden, wenn Sie Eigenschaften hinzufügen möchten oder was auch immer die Datenbank nicht wissen muss.Sie können sie einfach in die gleiche Klasse hinzufügen, solange Sie der richtigen Syntax folgen.Heck, Sie können sogar eine Modell für das Modell generieren. Eedmx -Datei, um Ihren Code zu visualisieren, wenn Sie möchten.

2) Größere Kontrolle

Wenn Sie zuerst DB gehen, sind Sie der Gnade dessen ausgeliefert, was für Ihre Modelle für die Verwendung in Ihrer Anwendung generiert wird.Gelegentlich ist die Namenskonvention unerwünscht.Manchmal sind die Beziehungen und Assoziationen nicht ganz das, was Sie wollen.In anderen Fällen, in denen nicht transiente Beziehungen mit faulen Ladung auf Ihre API -Antworten führen.

Während es fast immer eine Lösung für die Modellgenerierungsprobleme gibt, auf die Sie möglicherweise stoßen, gibt es Ihnen zuerst eine vollständige und feinkörnige Kontrolle von Anfang an.Sie können jeden Aspekt sowohl Ihrer Codemodelle als auch Ihres Datenbankdesigns bequem Ihr Geschäftsobjekt steuern.Sie können Beziehungen, Einschränkungen und Assoziationen genau angeben.Sie können gleichzeitig Eigenschaftszeichenlimits und Datenbankspaltengrößen festlegen.Sie können angeben, welche verwandten Sammlungen eifrig geladen werden sollen oder überhaupt nicht serialisiert werden.Kurz gesagt, Sie sind für mehr Dinge verantwortlich, aber Sie haben die volle Kontrolle über Ihr App -Design.

3)Datenbankversionskontrolle

Das ist eine große Sache.Versionsdatenbanken sind schwierig, aber mit Code First und Code First Migrations ist es viel effektiver.Da Ihr Datenbankschema vollständig auf Ihren Codemodellen basiert, können Sie durch die Version Ihres Quellcodes bei der Version Ihrer Datenbank helfen.Sie sind dafür verantwortlich, Ihre Kontextinitialisierung zu kontrollieren, die Ihnen helfen kann, Dinge wie Saatgut -Fixed -Geschäftsdaten zu tun.Sie sind auch dafür verantwortlich, Code First Migrations zu erstellen.

Wenn Sie Migrationen zum ersten Mal aktivieren, werden eine Konfigurationsklasse und eine anfängliche Migration generiert.Die anfängliche Migration ist Ihr aktuelles Schema oder Ihr Basis -V1.0.Ab diesem Zeitpunkt werden Sie Migrationen hinzufügen, die mit einem Deskriptor mit dem Zeitstempel und der Bezeichnung der Versionen zur Bestellung von Versionen gekennzeichnet sind.Wenn Sie die Add-Migration vom Paketmanager aufrufen, wird eine neue Migrationsdatei generiert, die alles enthält, was in Ihrem Codemodell automatisch in einer UP ()- und Down () -Funktion geändert wurde.Die UP -Funktion wendet die Änderungen in der Datenbank an. Die Down -Funktion beseitigt die gleichen Änderungen, in denen Sie Rollback möchten.Darüber hinaus können Sie diese Migrationsdateien bearbeiten, um zusätzliche Änderungen wie neue Ansichten, Indizes, gespeicherte Prozeduren und was auch immer sonst hinzuzufügen.Sie werden ein echtes Versionssystem für Ihr Datenbankschema.

Code-First scheint der aufstrebende Stern zu sein.Ich habe einen kurzen Blick auf Ruby on Rails geworfen und ihr Standard ist Code-First mit Datenbankmigrationen.

Wenn Sie eine MVC3-Anwendung erstellen, hat Code First meiner Meinung nach die folgenden Vorteile:

  • Einfache Attributdekoration - Sie können Felder mit Validierung, Anforderung usw. dekorieren.Attribute ist es bei der EF-Modellierung ziemlich umständlich
  • Keine seltsamen Modellierungsfehler - Bei der EF-Modellierung treten häufig seltsame Fehler auf. Wenn Sie beispielsweise versuchen, eine Assoziationseigenschaft umzubenennen, muss diese mit den zugrunde liegenden Metadaten übereinstimmen – sehr unflexibel.
  • Das Zusammenführen ist nicht umständlich - Bei der Verwendung von Tools zur Codeversionskontrolle wie Mercurial ist das Zusammenführen von .edmx-Dateien mühsam.Sie sind ein Programmierer, der mit C# vertraut ist, und führen dort eine .edmx-Datei zusammen.Nicht so bei Code-First.
  • Kehren Sie zunächst zum Code zurück, und Sie haben die vollständige Kontrolle, ohne dass Sie sich mit all den versteckten Komplexitäten und Unbekannten auseinandersetzen müssen.
  • Ich empfehle Ihnen, das Befehlszeilentool Package Manager zu verwenden und nicht einmal die grafischen Tools zu verwenden, um einen neuen Controller zu Gerüstansichten hinzuzufügen.
  • DB-Migrationen - Dann können Sie auch Migrationen aktivieren.Das ist so mächtig.Sie nehmen Änderungen an Ihrem Modell im Code vor, und dann kann das Framework Schemaänderungen verfolgen, sodass Sie Upgrades nahtlos bereitstellen können, wobei Schemaversionen automatisch aktualisiert (und bei Bedarf herabgestuft) werden.(Ich bin mir nicht sicher, aber das funktioniert wahrscheinlich auch mit Model-First)

Aktualisieren

Die Frage erfordert auch einen Vergleich von Code-First mit EDMX-Modell/DB-First.Code-First kann auch für beide dieser Ansätze verwendet werden:

Ich verwende zuerst die EF-Datenbank, um mehr Flexibilität und Kontrolle über die Datenbankkonfiguration zu bieten.

EF-Code zuerst und Modell zuerst schienen zunächst cool zu sein und bieten Datenbankunabhängigkeit, allerdings können Sie dabei nicht angeben, was ich als sehr grundlegende und allgemeine Datenbankkonfigurationsinformationen betrachte.Zum Beispiel Tabellenindizes, Sicherheitsmetadaten oder ein Primärschlüssel mit mehr als einer Spalte.Ich möchte diese und andere gängige Datenbankfunktionen nutzen und muss daher ohnehin einige Datenbankkonfigurationen direkt vornehmen.

Ich finde, dass die standardmäßigen POCO-Klassen, die zuerst während der Datenbank generiert werden, sehr sauber sind, ihnen jedoch die sehr nützlichen Datenanmerkungsattribute oder Zuordnungen zu gespeicherten Prozeduren fehlen.Ich habe die T4-Vorlagen verwendet, um einige dieser Einschränkungen zu überwinden.T4-Vorlagen sind großartig, besonders wenn sie mit Ihren eigenen Metadaten und Teilklassen kombiniert werden.

Das Modell scheint zunächst viel Potenzial zu haben, bereitet mir aber bei der Umgestaltung komplexer Datenbankschemata viele Fehler.Nicht sicher warum.

Die Arbeit mit großen Modellen war vor dem SP1 sehr langsam (ich habe es nach dem SP1 nicht ausprobiert, aber es heißt, dass es jetzt ein Kinderspiel ist).

Ich entwerfe immer noch zuerst meine Tabellen, dann generiert ein intern entwickeltes Tool die POCOs für mich, sodass ich mir die Last erspare, sich wiederholende Aufgaben für jedes Poco-Objekt zu erledigen.

Wenn Sie Versionsverwaltungssysteme verwenden, können Sie den Verlauf Ihrer POCOs problemlos verfolgen. Mit vom Designer generiertem Code ist das nicht so einfach.

Ich habe eine Basis für meinen POCO, die viele Dinge ganz einfach macht.

Ich habe Ansichten für alle meine Tabellen, jede Basisansicht bringt grundlegende Informationen für meine Fremdschlüssel und meine Ansichts-POCOs werden von meinen POCO-Klassen abgeleitet, was wiederum sehr nützlich ist.

Und schließlich mag ich keine Designer.

Beispiel für den Datenbank-First-Ansatz:

Ohne Code zu schreiben:ASP.NET MVC / MVC3-Datenbank erster Ansatz / Datenbank zuerst

Und ich denke, es ist besser als andere Ansätze, weil der Datenverlust bei diesem Ansatz geringer ist.

Meiner Meinung nach haben alle Modelle einen guten Platz, aber das Problem, das ich mit dem Model-First-Ansatz habe, ist, dass man in vielen großen Unternehmen, in denen DBAs die Datenbanken steuern, nicht die Flexibilität erhält, Anwendungen zu erstellen, ohne Database-First-Ansätze zu verwenden.Ich habe an vielen Projekten gearbeitet und als es um die Bereitstellung ging, wollten sie die volle Kontrolle.

So sehr ich mit allen möglichen Variationen „Code zuerst“, „Modell zuerst“ und „Datenbank zuerst“ einverstanden bin, müssen Sie die tatsächliche Produktionsumgebung berücksichtigen.Wenn es sich bei Ihrem System also um eine Anwendung mit großer Benutzerbasis handelt, bei der viele Benutzer und Datenbankadministratoren das Sagen haben, dann könnten Sie meiner Meinung nach die Option „Datenbank zuerst“ in Betracht ziehen.

Ich denke, einer der Vorteile von Code besteht erstens darin, dass Sie alle Änderungen, die Sie an einem Versionskontrollsystem wie Git vorgenommen haben, sichern können.Da alle Ihre Tabellen und Beziehungen in praktisch reinen Klassen gespeichert sind, können Sie in die Vergangenheit reisen und sehen, wie die Struktur Ihrer Datenbank vorher war.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top