it-swarm.com.de

Code-first vs Model / Database-first

Was sind die Vor- und Nachteile der Verwendung von Entity Framework 4.1 Code-first über Model/Database-first mit EDMX-Diagramm?

Ich versuche, alle Ansätze zum Erstellen der Datenzugriffsebene mit 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 manuell und optimiere das Schema mit ModelBuilder.

Ich kann auch ein EDMX Diagramm erstellen und einen Codegenerierungsschritt auswählen, der T4-Vorlagen verwendet, um die gleichen POCO Klassen zu generieren.

In beiden Fällen ende ich mit POCO Objekten, die ORM agnostisch sind, und einem Kontext, der von DbContext herrührt.

Database-first scheint am ansprechendsten zu sein, da ich Datenbanken in Enterprise Manager entwerfen, das Modell schnell synchronisieren und mithilfe des Designers optimieren kann.

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

598
Jakub Konecki

Ich denke die Unterschiede sind:

Code zuerst

  • Sehr beliebt, weil Hardcore-Programmierer keine Designer mögen und das Definieren von Mapping in EDMX xml zu komplex ist.
  • Volle Kontrolle über den Code (kein automatisch generierter Code, der schwer zu ändern ist).
  • Allgemeine Erwartung ist, dass Sie sich nicht mit DB beschäftigen. DB ist nur ein Speicher ohne Logik. EF kümmert sich um die Erstellung und Sie möchten nicht wissen, wie es die Arbeit macht.
  • Manuelle Änderungen an der Datenbank gehen höchstwahrscheinlich verloren, da der Code die Datenbank definiert.

Datenbank zuerst

  • Sehr beliebt, wenn Sie DB von DBAs entworfen, separat entwickelt oder über eine vorhandene DB verfügen.
  • Sie lassen EF Entitäten für Sie erstellen und generieren nach Änderung des Mappings 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 über die Datenbank aktualisieren (diese Funktion funktioniert recht gut).
  • Ich benutze dies oft zusammen mit VS Database-Projekten (nur Premium- und Ultimate-Version).

Modell zuerst

  • IMHO beliebt, wenn Sie Designer-Fan sind (= Sie schreiben keinen 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 sowohl über Ihre Entitäten als auch über die Datenbank, aber für kleine, einfache Projekte sind Sie 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 ein Netzteil für die 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 gibt, die sich auf Code First vs. Model/Database First beziehen. Die in Code first verwendete Fluent-API bietet nicht alle Funktionen von EDMX. Ich gehe davon aus, dass Funktionen wie Zuordnung gespeicherter Prozeduren, Abfrageansichten, Definieren von Ansichten usw. funktionieren, wenn zuerst Modell/Datenbank und DbContext verwendet werden (ich habe es noch nicht ausprobiert), aber nicht zuerst im Code.

683
Ladislav Mrnka

Ich denke, dieser einfache "Entscheidungsbaum" von Julie Lerman, der Autorin des "Programming Entity Framework", sollte dazu beitragen, die Entscheidung mit mehr Vertrauen zu treffen:

a decision tree to help choosing different approaches with EF

Weitere Infos hier .

127

Datenbank zuerst und Modell zuerst hat keine wirklichen Unterschiede. Der generierte Code ist derselbe und Sie können diese Ansätze kombinieren. Beispielsweise können Sie eine Datenbank mit Designer erstellen, dann können Sie die Datenbank mit 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. IMHO ist diese Einschränkung sehr streng und erlaubt nicht, Code zuerst in der Produktion zu verwenden. Im Moment ist es nicht wirklich verwendbar.

Der zweite kleine Nachteil von Code First ist, dass Model Builder Berechtigungen für die master-Datenbank benötigen. Dies hat keine Auswirkungen auf Sie, wenn Sie eine SQL Server Compact-Datenbank verwenden oder den Datenbankserver steuern.

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

Ich kann die Verwendung des Code-First-Ansatzes empfehlen, wenn Sie eine einfache eigenständige Anwendung ohne Versionierung erstellen und in Projekten, die Änderungen in der Produktion erfordern, zuerst model\database verwenden.

51
Stepan Smagin

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 aufblähen

Die Verwendung einer vorhandenen Datenbank zum Generieren einer EDMX-Modelldatei und der zugehörigen Codemodelle führt zu einem riesigen Stapel automatisch generierten Codes. Sie werden gebeten, diese generierten Dateien niemals zu berühren, um zu verhindern, dass Sie etwas beschädigen oder Ihre Änderungen bei der nächsten Generation überschrieben werden. Der Kontext und der Initialisierer sind auch in diesem Durcheinander zusammengewürfelt. Wenn Sie Ihren generierten Modellen Funktionen hinzufügen möchten, z. B. eine berechnete schreibgeschützte Eigenschaft, müssen Sie die Modellklasse erweitern. Dies ist eine Voraussetzung für fast jedes Modell, und Sie erhalten eine Erweiterung für alles.

Mit code first werden Ihre handcodierten Modelle zu Ihrer Datenbank. Die genauen Dateien, die Sie erstellen, bestimmen das Datenbankdesign. Es gibt keine zusätzlichen Dateien und es ist nicht erforderlich, eine Klassenerweiterung zu erstellen, wenn Sie Eigenschaften hinzufügen möchten oder was auch immer die Datenbank sonst noch wissen muss. Sie können sie einfach derselben Klasse hinzufügen, solange Sie der richtigen Syntax folgen. Sie können sogar eine Model.edmx-Datei generieren, um Ihren Code zu visualisieren, wenn Sie möchten.

2) Größere Kontrolle

Wenn Sie zum ersten Mal zur Datenbank wechseln, sind Sie dem ausgeliefert, was für Ihre Modelle zur 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 können nicht vorübergehende Beziehungen mit verzögertem Laden Ihre API-Antworten in Mitleidenschaft ziehen.

Während es für Probleme bei der Modellgenerierung fast immer eine Lösung gibt, können Sie durch das Ausführen von Code von Anfang an eine vollständige und fein abgestimmte Kontrolle erhalten. Sie können jeden Aspekt sowohl Ihrer Codemodelle als auch Ihres Datenbankentwurfs bequem von Ihrem Geschäftsobjekt aus steuern. Sie können Beziehungen, Einschränkungen und Zuordnungen genau angeben. Sie können gleichzeitig Eigenschaftszeichenbeschränkungen und Datenbankspaltengrößen festlegen. Sie können angeben, welche verwandten Sammlungen schnell geladen oder gar nicht serialisiert werden sollen. Kurz gesagt, Sie sind für mehr Dinge verantwortlich, haben aber die volle Kontrolle über Ihr App-Design.

3) Versionskontrolle der Datenbank

Dies ist eine große. Das Versionsmanagement von Datenbanken ist schwierig, aber mit Code-First- und Code-First-Migrationen ist es viel effektiver. Da Ihr Datenbankschema vollständig auf Ihren Codemodellen basiert, helfen Sie durch die Versionskontrolle Ihres Quellcodes, Ihre Datenbank zu versionieren. Sie sind für die Steuerung Ihrer Kontextinitialisierung verantwortlich, die Ihnen dabei helfen kann, beispielsweise festgelegte Geschäftsdaten zu erstellen. Sie sind auch für die Erstellung der ersten Codemigrationen verantwortlich.

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 Ihre Baseline v1.0. Ab diesem Zeitpunkt werden Sie Migrationen hinzufügen, die mit einem Zeitstempel versehen und mit einem Deskriptor versehen sind, um die Bestellung von Versionen zu erleichtern. Wenn Sie add-migration vom Paketmanager aus aufrufen, wird eine neue Migrationsdatei generiert, die alle Änderungen in Ihrem Codemodell automatisch in einer UP- () und einer DOWN- () Funktion enthält. Die UP-Funktion wendet die Änderungen auf die Datenbank an. Die DOWN-Funktion entfernt dieselben Änderungen für den Fall, dass Sie ein Rollback durchführen möchten. Darüber hinaus können Sie diese Migrationsdateien bearbeiten, um zusätzliche Änderungen wie neue Ansichten, Indizes, gespeicherte Prozeduren usw. hinzuzufügen. Sie werden zu einem echten Versionsverwaltungssystem für Ihr Datenbankschema.

35
Jahan

Code-first scheint der aufsteigende Stern zu sein. Ich habe mir Ruby on Rails kurz angesehen und ihr Standard ist Code-first mit Datenbankmigrationen.

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

  • Einfache Attributdekoration - Sie können Felder mit Validierungs-, Bedarfs- usw. Attributen dekorieren. Bei der EF-Modellierung ist dies recht umständlich
  • Keine seltsamen Modellierungsfehler - Beim EF-Modellieren treten häufig seltsame Fehler auf. Wenn Sie beispielsweise versuchen, eine Assoziationseigenschaft umzubenennen, muss sie mit den zugrunde liegenden Metadaten übereinstimmen - sehr unflexibel.
  • Nicht umständlich zusammenzuführen - Wenn Sie Tools zur Versionskontrolle von Code wie Mercurial verwenden, ist das Zusammenführen von .edmx-Dateien mühsam. Sie sind ein Programmierer, der an C # gewöhnt ist, und führen dort eine EDMX-Datei zusammen. Nicht so bei Code-First.
  • Wenn Sie sich wieder mit Code beschäftigen, haben Sie die vollständige Kontrolle, ohne all die versteckten Komplexitäten und Unbekannten, mit denen Sie sich befassen müssen.
  • Ich empfehle, das Befehlszeilentool Package Manager zu verwenden. Verwenden Sie nicht einmal die grafischen Tools, um Gerüstansichten einen neuen Controller 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 nachverfolgen, sodass Sie Upgrades nahtlos bereitstellen können. Dabei werden die Schemaversionen automatisch aktualisiert (und bei Bedarf heruntergestuft). (Ich bin mir nicht sicher, aber das funktioniert wahrscheinlich auch mit model-first)

Update

In der Frage wird auch nach einem Vergleich von Code-First mit EDMX-Modell/DB-First gefragt. Code-first kann auch für beide dieser Ansätze verwendet werden:

29
Todd

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

EF-Code zuerst und Modell zuerst schienen zunächst cool zu sein und bieten Datenbankunabhängigkeit. Dabei können Sie jedoch nicht angeben, was ich für sehr grundlegende und allgemeine Informationen zur Datenbankkonfiguration halte. Beispielsweise Tabellenindizes, Sicherheitsmetadaten oder Primärschlüssel mit mehr als einer Spalte. Ich möchte diese und andere gängige Datenbankfunktionen nutzen und muss daher sowieso einige Datenbankkonfigurationen direkt vornehmen.

Ich finde, dass die Standard-POCO-Klassen, die während der Datenbankerstellung generiert werden, sehr sauber sind, jedoch keine sehr nützlichen Datenanmerkungsattribute oder Zuordnungen zu gespeicherten Prozeduren aufweisen. Ich habe die T4-Vorlagen verwendet, um einige dieser Einschränkungen zu überwinden. T4-Vorlagen sind fantastisch, insbesondere wenn sie mit Ihren eigenen Metadaten und Teilklassen kombiniert werden.

Das Modell scheint zunächst viel Potenzial zu haben, aber es gibt mir viele Fehler beim Umgestalten komplexer Datenbankschemata. Nicht sicher warum.

11
user1618371

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

Ich entwerfe immer noch zuerst meine Tabellen, dann generiert ein intern erstelltes Tool die POCOs für mich, sodass es die Last ist, sich wiederholende Aufgaben für jedes Poco-Objekt auszuführen.

wenn Sie Quellcodeverwaltungssysteme verwenden, können Sie den Verlauf Ihrer POCOs problemlos verfolgen. Mit vom Designer generiertem Code ist dies nicht so einfach.

Ich habe eine Basis für mein POCO, was eine Menge Dinge ziemlich einfach macht.

Ich habe Ansichten für alle meine Tabellen, jede Basisansicht enthält grundlegende Informationen für meine Fremdschlüssel und meine Ansichts-POCOs stammen aus meinen POCO-Klassen, was wiederum sehr nützlich ist.

Und schließlich mag ich keine Designer.

6
hazimdikenli

Beispiel für den ersten Ansatz der Datenbank:

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

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

5
AukI

IMHO denke ich, dass alle Modelle einen großartigen Platz haben, aber das Problem, das ich mit dem ersten Ansatz des Modells habe, besteht in vielen großen Unternehmen, in denen DBAs die Datenbanken kontrollieren. Sie erhalten nicht die Flexibilität, Anwendungen zu erstellen, ohne erste Datenbankansätze zu verwenden. Ich habe an vielen Projekten gearbeitet, und wenn es um die Bereitstellung ging, wollten sie die volle Kontrolle.

So weit ich mit allen möglichen Variationen einverstanden bin, müssen Sie zuerst die tatsächliche Produktionsumgebung berücksichtigen. Wenn Ihr System also eine große Anwenderbasis mit vielen Anwendern und Datenbankadministratoren sein soll, die die Show ausführen, dann könnten Sie die erste Option der Datenbank in Betracht ziehen, nur meiner Meinung nach.

3
Matthew Parton