Code-first vs Model / Database-first

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

Weitere Infos hier .

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.

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.

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:

• Model-First : Zuerst die POCOs (das konzeptionelle Modell) codieren und dann die Datenbank erzeugen (Migrationen) ; ODER
• Database-First : Bei einer vorhandenen Datenbank manuelles Codieren der zu vergleichenden POCOs. (Der Unterschied besteht darin, dass die POCOs nicht automatisch generiert werden, wenn eine Datenbank vorhanden ist). Sie können jedoch mit Generieren von POCO-Klassen und Zuordnen für eine vorhandene Datenbank mit Entity Framework oder Entity Framework 5 - Generieren von POCO-Klassen aus einer vorhandenen Datenbank fast automatisch vorgehen.

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.

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.

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.

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.