Code-first vs. Model/Database-first

Question

Was sind die Vor- und Nachteile der 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 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: Definieren Sie meine Entitäten und den Kontext von Hand und verwenden Sie ModelBuilder zur Feinabstimmung des Schemas.

Ich kann auch eine EDMX Diagramm und wählen Sie einen Codegenerierungsschritt, der T4-Vorlagen verwendet, um dieselbe POCO Klassen.

In beiden Fällen lande ich bei POCO Objekt, die ORM agnostisch und Kontext, der sich aus DbContext .

Database-first scheint mir am attraktivsten zu sein, da ich die Datenbank in Enterprise Manager entwerfen, das Modell schnell synchronisieren und mit dem Designer fein abstimmen kann.

Worin besteht nun der Unterschied zwischen diesen beiden Ansätzen? Geht es nur um die Präferenz VS2010 vs. Enterprise Manager?

Answer 1

Ich denke, das sind die Unterschiede:

Erster Code

• Sehr beliebt, weil Hardcore-Programmierer keine Designer mögen und die Definition des Mappings in EDMX xml zu komplex ist.
• Volle Kontrolle über den Code (kein automatisch generierter Code, der schwer zu ändern ist).
• Im Allgemeinen wird erwartet, dass Sie sich nicht um die DB kümmern. DB ist nur ein Speicher mit keiner Logik. EF kümmert sich um die Erstellung, und Sie wollen nicht wissen, wie es die Arbeit erledigt.
• Manuelle Änderungen an der Datenbank gehen höchstwahrscheinlich verloren, da Ihr Code die Datenbank definiert.

Datenbank zuerst

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

Erstes Modell

• IMHO beliebt, wenn Sie ein Designer-Fan sind (= Sie schreiben nicht gerne Code oder SQL).
• Sie "zeichnen" Ihr Modell und lassen Workflow Ihr Datenbankskript und die T4-Vorlage Ihre POCO-Entitäten generieren. Sie werden einen Teil der Kontrolle über Ihre Entitäten und Ihre Datenbank verlieren, aber für kleine, einfache Projekte werden Sie sehr produktiv sein.
• Wenn Sie zusätzliche Funktionen in POCO-Entitäten wünschen, müssen Sie entweder die T4-Vorlage ändern oder partielle Klassen verwenden.
• Manuelle Änderungen an der Datenbank gehen höchstwahrscheinlich verloren, da Ihr Modell die Datenbank definiert. Dies funktioniert besser, wenn Sie das Datenbankgenerierungs-Powerpack 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 Falle von EF 4.1 mehrere andere Funktionen im Zusammenhang mit Code First vs. Model/Database first gibt. Die in Code first verwendete Fluent API bietet nicht alle Funktionen von EDMX. Ich erwarte, dass Funktionen wie Stored Procedures Mapping, Query Views, Defining Views usw. funktionieren, wenn Model/Database first verwendet wird und DbContext (Ich habe es noch nicht ausprobiert), aber sie tun es nicht in Code first.

Answer 2

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

Mehr Infos Hier .

Answer 3

Zwischen "Database first" und "Model first" gibt es keine wirklichen Unterschiede. Der generierte Code ist derselbe und Sie können diese Ansätze kombinieren. Zum Beispiel können Sie eine Datenbank mit dem Designer erstellen, dann können Sie die Datenbank 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. IMHO, diese Einschränkung ist sehr streng und erlaubt es nicht, Code zuerst in der Produktion zu verwenden. Für jetzt ist es nicht wirklich brauchbar.

Der zweite kleine Nachteil von Code first besteht darin, dass der Model Builder Berechtigungen für die Master-Datenbank benötigt. Dies betrifft Sie nicht, wenn Sie SQL Server Compact-Datenbank verwenden oder wenn Sie Datenbank-Server 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 leicht ändern und als Ihr Ansichtsmodell verwenden.

Ich empfehle die Verwendung des Code-First-Ansatzes, wenn Sie eine einfache Standalone-Anwendung ohne Versionierung und mit Modell erstellen \database zuerst bei Projekten, die Änderungen in der Produktion erfordern.

Answer 4

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

3 Gründe für die Verwendung von Code First Design mit Entity Framework

1) Weniger Ballast, weniger Blähungen

Verwendung einer bestehenden Datenbank zur Erstellung einer .edmx-Modelldatei und der Die Verwendung einer bestehenden Datenbank zur Generierung einer .edmx-Modelldatei und der zugehörigen Code-Modelle führt zu einem riesigen Haufen automatisch generierten Codes. Sie werden angefleht, diese generierten Dateien niemals anzurühren, damit Sie nicht etwas kaputt zu machen, oder Ihre Änderungen werden bei der nächsten Generation überschrieben. Der Kontext und der Initialisierer sind in diesem Durcheinander auch noch zusammengeklemmt. Wenn Sie Ihren generierten Modellen Funktionalität hinzufügen müssen, wie eine berechnete schreibgeschützte Eigenschaft, müssen Sie die Modellklasse erweitern. Dies ist am Ende eine Anforderung für fast jedes Modell und man hat am Ende mit einer Erweiterung für alles.

Mit Code first werden Ihre handcodierten Modelle zu Ihrer Datenbank. Die genauen Dateien, die Sie erstellen, erzeugen das Datenbankdesign. Es gibt keine zusätzlichen Dateien und es ist nicht notwendig, eine Klassen Erweiterung zu erstellen, wenn Sie Eigenschaften oder andere Dinge hinzufügen wollen, die die die die Datenbank nicht kennen muss. Sie können sie einfach in dieselbe derselben Klasse hinzufügen, solange Sie die korrekte Syntax einhalten. Sie können sogar eine Model.edmx-Datei erzeugen, um Ihren Code zu visualisieren, wenn Sie wollen.

2) Größere Kontrolle

Wenn Sie zuerst die DB verwenden, sind Sie der Gnade dessen ausgeliefert, was für Ihre Modelle für die Verwendung in Ihrer Anwendung. Gelegentlich ist die Namensgebung Konvention unerwünscht. Manchmal sind die Beziehungen und Assoziationen nicht ganz das, was Sie wollen. Andere Male sind nicht transiente Beziehungen mit trägem Laden Ihre API-Antworten in Mitleidenschaft ziehen.

Zwar gibt es fast immer eine Lösung für Probleme bei der Modellerstellung gibt es zwar fast immer eine Lösung für Probleme bei der Modellerstellung, aber wenn Sie zuerst den Code Kontrolle von Anfang an. Sie können jeden Aspekt sowohl von Ihrer Code-Modelle und Ihres Datenbankdesigns von Ihrem Geschäftsobjekts. Sie können Beziehungen, Einschränkungen und Assoziationen genau festlegen, und Assoziationen. Sie können gleichzeitig Grenzen für Eigenschaftszeichen und Datenbankspaltengrößen festlegen. Sie können angeben, welche verwandten Sammlungen eager geladen oder überhaupt nicht serialisiert werden sollen. Kurz gesagt, Sie sind verantwortlich für mehr Dinge, aber Sie haben die volle Kontrolle über Ihre Anwendung Entwurf.

3) Datenbank-Versionskontrolle

Das ist eine große Sache. Die Versionierung von Datenbanken ist schwierig, aber mit Code first und "Code first"-Migrationen ist es viel effektiver. Da Ihr Datenbankschema vollständig auf Ihren Code-Modellen basiert, tragen Sie durch die Versionskontrolle Versionskontrolle Ihres Quellcodes helfen Sie bei der Versionierung Ihrer Datenbank. Sie sind verantwortlich für die Kontrolle der Kontextinitialisierung, die Sie können z. B. feste Geschäftsdaten einfügen. Sie sind auch für die Erstellung von Code-First-Migrationen verantwortlich.

Wenn Sie Migrationen zum ersten Mal aktivieren, werden eine Konfigurationsklasse und eine erste Migration erzeugt. Die anfängliche Migration ist Ihr aktuelles Schema oder Ihr Basisschema v1.0. Von diesem Zeitpunkt an werden Sie Migrationen hinzufügen die mit einem Zeitstempel versehen und mit einem Deskriptor versehen werden, um die Ordnung der Versionen zu helfen. Wenn Sie add-migration über den Paketmanager aufrufen Manager aufrufen, wird eine neue Migrationsdatei erzeugt, die alles enthält die sich in Ihrem Codemodell geändert haben, automatisch in einer UP() und DOWN()-Funktion. Die UP-Funktion wendet die Änderungen auf die Datenbank an, die DOWN-Funktion entfernt dieselben Änderungen für den Fall, dass Sie einen Rollback. Darüber hinaus können Sie diese Migrationsdateien bearbeiten und Folgendes hinzufügen zusätzliche Änderungen wie neue Ansichten, Indizes, gespeicherte Prozeduren und was auch immer sonst. Sie werden so zu einem echten Versionierungssystem für Ihr Datenbankschema.

Answer 5

Code-first scheint der aufsteigende 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:

• Einfaches Attribut Dekoration - Sie können Felder mit Attributen wie Validierung, Erfordernis usw. ausstatten, was bei der EF-Modellierung ziemlich umständlich ist.
• Keine seltsamen Modellierungsfehler - Bei der EF-Modellierung treten oft seltsame Fehler auf, z. B. wenn man versucht, eine Assoziationseigenschaft umzubenennen, muss sie mit den zugrunde liegenden Metadaten übereinstimmen - sehr unflexibel.
• Nicht umständlich zu fusionieren - Bei der Verwendung von Code-Versionskontrollwerkzeugen wie Mercurial ist das Zusammenführen von .edmx-Dateien ein Problem. Sie sind ein Programmierer, der an C# gewöhnt ist, und Sie müssen eine .edmx-Datei zusammenführen. Nicht so bei Code-First.
• Im Gegensatz zum ersten Code haben Sie die vollständige Kontrolle, ohne sich mit all den versteckten Komplexitäten und Unbekannten auseinandersetzen zu müssen.
• Ich empfehle Ihnen, das Befehlszeilentool des Paketmanagers zu verwenden und nicht einmal die grafischen Tools zu benutzen, um einen neuen Controller zu den Gerüstansichten hinzuzufügen.
• DB-Migrationen - Dann können Sie auch Migrationen aktivieren. Das ist sehr mächtig. Sie nehmen Änderungen an Ihrem Modell im Code vor, und das Framework kann dann die Schemaänderungen verfolgen, so dass Sie nahtlos Upgrades bereitstellen können, wobei die Schemaversionen automatisch aktualisiert (und bei Bedarf heruntergestuft) werden. (Ich bin mir nicht sicher, aber das funktioniert wahrscheinlich auch mit Model-First)

更新情報

In der Frage wird auch nach einem Vergleich zwischen Code-first und EDMX model/db-first gefragt. Code-first kann auch für diese beiden Ansätze verwendet werden:

• Model-First : Zuerst die POCOs kodieren (das konzeptionelle Modell), dann Erzeugung von die Datenbank (Migrationen); ODER
• Datenbank-First : Gegeben eine bestehende Datenbank, manuell die POCOs entsprechend zu kodieren. (Der Unterschied besteht darin, dass die POCOs nicht automatisch aus der vorhandenen Datenbank generiert werden). Sie können sich jedoch der Automatik annähern, indem Sie Generierung von POCO-Klassen und des Mappings für eine bestehende Datenbank mit Entity Framework o Entity Framework 5 - Wie man POCO-Klassen aus einer bestehenden Datenbank generiert .