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 verwende zunächst die EF-Datenbank, um mehr Flexibilität und Kontrolle über die Datenbankkonfiguration zu haben.

EF code first and model first schien zunächst cool zu sein und bietet Datenbankunabhängigkeit, aber dabei können Sie nicht angeben, was ich für sehr grundlegende und allgemeine Datenbankkonfigurationsinformationen halte. Zum Beispiel Tabellenindizes, Sicherheits-Metadaten 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 Standard-POCO-Klassen, die während der DB-Erstellung generiert werden, sehr sauber sind, jedoch fehlen die sehr nützlichen Attribute für Datenannotationen oder Zuordnungen zu gespeicherten Prozeduren. Ich habe die T4-Vorlagen verwendet, um einige dieser Einschränkungen zu überwinden. T4-Vorlagen sind großartig, vor allem wenn man sie mit eigenen Metadaten und Teilklassen kombiniert.

Model first scheint viel Potenzial zu haben, verursacht aber viele Fehler beim Refactoring komplexer Datenbankschemata. Nicht sicher, warum.

Answer 2

Das Arbeiten 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, und dann generiert ein selbst entwickeltes Tool die POCOs für mich, so dass ich nicht mehr für jedes Poco-Objekt wiederholte Aufgaben erledigen muss.

Bei der Verwendung von Versionskontrollsystemen können Sie die Historie Ihrer POCOs leicht nachvollziehen, bei vom Designer generiertem Code ist das nicht so einfach.

Ich habe einen Sockel für meinen POCO, der mir vieles erleichtert.

Ich habe Ansichten für alle meine Tabellen, jede Basisansicht bringt grundlegende Informationen für meine Fremdschlüssel und meine Ansicht POCOs leiten von meinen POCO-Klassen, die wieder ziemlich nützlich ist.

Und schließlich mag ich keine Designer.

Answer 3

Beispiel für den ersten Ansatz einer Datenbank:

Ohne irgendeinen Code zu schreiben: ASP.NET MVC / MVC3 Database First Approach / Datenbank zuerst

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

Answer 4

IMHO bin ich der Meinung, dass alle Modelle ihren Platz haben, aber das Problem, das ich mit dem "Model First"-Ansatz habe, ist, dass man in vielen großen Unternehmen mit DBAs, die die Datenbanken kontrollieren, nicht die Flexibilität hat, Anwendungen zu entwickeln, ohne die Datenbank zuerst zu verwenden. Ich habe an vielen Projekten gearbeitet, und als es um die Bereitstellung ging, wollten sie die volle Kontrolle.

So sehr ich auch allen möglichen Varianten Code First, Model First, Database First zustimme, müssen Sie die tatsächliche Produktionsumgebung berücksichtigen. Wenn Ihr System also eine Anwendung für eine große Benutzerbasis mit vielen Benutzern und DBAs sein wird, dann sollten Sie die Option "Datenbank zuerst" in Betracht ziehen - nur meine Meinung.

Answer 5

Ich denke, einer der Vorteile von Code First ist, dass man alle Änderungen, die man vorgenommen hat, in einem Versionskontrollsystem wie Git sichern kann. Da alle Ihre Tabellen und Beziehungen in Klassen gespeichert sind, können Sie in der Zeit zurückgehen und sehen, wie die Struktur Ihrer Datenbank vorher aussah.