Entity Framework: Database first vs. Code first: Geben ich bei Code-First nicht die Kontrolle ab?

verwendetes Datenbanksystem: SQL Server, EF6

Hallo allerseits,

ich weiß, es gibt diverse Artikel zu diesem Thema im Netz. Trotzdem würden mich mal Eure Meinungen zu dieser Frage interessieren.

Ich persönlich bevorzuge Database First, da man hier volle Kontrolle über das Datenbank-Schema hat.

Gleichzeitig weiß ich, dass bei EF Core nur noch Code First unterstützt wird.

Bauchschmerzen bzgl. Code First habe ich vor allem, weil ich - nach meinem Verständnis von Code First - die Kontrolle über das Datenbank-Schema komplett abgebe.

Indexe, Constraints, etc., werden doch "normalerweise" in einem SQL-Skript definiert. Ich kann mir schwer vorstellen, dass ein reales Projekt mit 100 oder mehr Tabellen mit Code First umsetzbar ist. Ich benötige doch zumindest ein SQL-Skript, in dem das Datenbank-Schema definiert ist. Schon alleine zur Dokumentation. Ebenfalls benötigt ja fast jede Applikation initiale Daten, die ja auch per SQL-Skript eingespielt werden. Wie soll das bei Code First gehen?

Gruß

Hallo sugar76,

ich vermute du hast ein kleines Verständnisproblem, denn auch mit Code-first kann gegen bestehende Datenbanken gemappt werden.

Database-first bezieht sich v.a. auf den EDMX-Editor, der so das Mapping von der bestehenden DB generiert (und angepasst werden kann).

Code-first erstellt das Mapping direkt duch Klassen, die entweder händisch erstellt werden od. per Reverse engineering aus einer bestehenden DB generiert werden können. Nota bene: auch die händisch erstellten Klassen können auf eine existierende DB mappen!

Persönlich hab ich die DB in einem SQL Server-Projekt in VS, das sich somit auch (per git) versionieren lässt. Der O/R-Code muss dann halt nachgezogen werden. Aber das ist mir lieber als die (automatischen) Migrationen (denen traue ich bei Live-Daten weniger als mir selbst 😉).

mfG Gü

Stimme gfoidl hier zu; Aussagen, dass man nur die Kontrolle per Database First hat, stimmen nicht.
Daher schließe ich mich auch an, dass Dein Verständnis große Lücken aufweist 😃

Ich persönlich nehme aber komplett Abstand vom EF.
Wir verwenden i.d.R. Dapper als Micro ORM. Für das Schema/die Migration FluentMigrator oder DACPAC-Projekte.

@gfoidl:

Ich schließe mich dessen an, wir auf Arbeit verwenden auch für die Datenbank im VS ein Datenbank-Projekt, das versioniert im GIT liegt, und bei dem man bei der MigrationScript-Erstellung wenigstens volle Kontrolle hat. Und in dem man zum Hochziehen der Produktiv-Datenbank auch noch Fehlerbehandlung oder Sonderbehandlungen einbauen kann 🙂
Für eine Testdatenbank ist es mir Latte, ob da Daten flöten gehen.

Gerade bei Strukturänderungen ist es ja auch eine Frage der Berechtigungen.
Denn Anwendungen/ Services sollten meiner Meinung nach gerade mal DataReader/ DataWriter sein, mehr nicht! Und das dann auch noch eingeschränkt.

lG, Marko

OK, d.h., Änderungen am DB-Schema können bei Code First entweder per Reverse Engineering oder händisch in den POCOs nachgezogen werden, das Datenbank-Schema wird separat gepflegt.

Dann frage ich mich, wo bei diesem Vorgehen denn der Vorteil von Code-First gegenüber Database First liegt? Abgesehen davon, dass es bei Verwendung von EF Core eh keine Alternative gibt.

.. das Datenbank-Schema wird separat gepflegt.

Genau das ist nicht der Fall, wenn du Code-First verwendest.

.. das Datenbank-Schema wird separat gepflegt.

Genau das ist nicht der Fall, wenn du Code-First verwendest.

Habe mich unklar ausgedrückt. Wenn man so vorgeht wie von gfoidl beschrieben, wird es eben doch separat gepflegt. Davon bin bei meinem Kommentar ausgegangen.

meine 5ct: Ich mag CodeFirst auch nicht besonders, weils da nicht mehr den Edmx-Designer gibt.
Der - als Entity-Relation-Diagramm - ist mir nämlich eine große Hilfe beim Konzipieren von Datenmodellen.
Bei CodeFirst habich Mühe, den Überblick zu behalten.
Ich gebe auch die Hoffnung nicht auf, dasses MS demnächst doch noch einfällt, auch EF.Core wieder mit ER-Diagramm-Designer-Unterstützung auszustatten.

@ErfinderDesRades, dann dürfte dich das interessieren:
https://github.com/ErikEJ/EFCorePowerTools/wiki

Hab ich selber nicht ausgetestet, aber klingt nach genau dem, was Du suchst.
Das spuckt am Ende genauso POCO-Klassen und einen DbContext aus, wie man es für CodeFirst braucht.

PS:
Ich hab das von da: https://docs.microsoft.com/de-de/ef/core/extensions/
Da gibt's noch ein paar mehr Links, die ich mir nicht angeschaut habe, aber die könnten ebenso spannend sein.

Hallo sugar76,

wo bei diesem Vorgehen denn der Vorteil von Code-First gegenüber Database First liegt?

Es gibt immer Vor- und Nachteile 😉

Als Vorteile sehe ich bei diesem Vorgehen mit Code-First (ohne bestimmte Reihenfolge):* die Modell-Klassen können leicht in eigenes Projekt ausgelagert werden

• die Modell-Klassen können leicht angepasst werden, falls mehr als nur POCOs nötig ist (ohne partielle Klassen, etc. verwenden zu müssen wie beim DB-first Ansatz)
• in den Modell-Klassen können alle C# Sprachfeatures wie Vererbung (gemeinsame Basisklassen), etc. angewandt werden (bei DB-first nur umständlich möglich)
• Verbindungszeichenfolge ist einfacher (da das edmx-Mapping entfällt) und somit kann sie universeller verwendet werden, bei DB-first ist sie sehr speziell für diesen einen Anwendungsfall
• Code ist leichter versionierbar bzw. Änderungen sind leichter nachvollziehbar (Änderung an Klassen vs. Änderung am edmx (XML))

Nachteile:* Designer (edmx) gibt es nicht -- ob dies wirklich ein Nachteil ist, soll jeder für sich entscheiden. Die Modell-Klassen können auch sonst visualisiert werden bei Bedarf.

• das Mapping ist teilweise schwerer zu coden als mit dem Designer von DB-first
• benötigt oft mehr Entwicklungs-Zeit bis die Anwendung auf die DB zugreifen kann, aber langfristig ist es i.d.R. besser wartbarer

Diese List ist sicher nicht vollständig und auch geprägt von persönlichen Vorlieben / Erfahrungen und somti auch als solches zu betrachten, aber ich hoffe dass es als Orientierung hilfreich ist.

mfG Gü

die Modell-Klassen können leicht in eigenes Projekt ausgelagert werden

die Modell-Klassen können leicht angepasst werden, falls mehr als nur POCOs nötig ist (ohne partielle Klassen, etc. verwenden zu müssen wie beim DB-first Ansatz)

in den Modell-Klassen können alle C# Sprachfeatures wie Vererbung (gemeinsame Basisklassen), etc. angewandt werden (bei DB-first nur umständlich möglich)

Ja stimmt, das liegt eigentlich auf der Hand - bei Code First (wie der Name schon sagt) habe ich halt volle Kontrolle über die Datenklassen/POCOs. Das geht bei DB First zwar auch irgendwie (z.B. durch Anpassung der T4-Templates), aber ist halt etwas aufwändiger.

Das geht bei DB First zwar auch irgendwie (z.B. durch Anpassung der T4-Templates), aber ist halt etwas aufwändiger.

T4 Scripts sind doch nur Code Generatoren. Du kannst DB First genauso ohne T4 Scripte laufen lassen.
Das hat gfoidl auch schon gesagt.

Lass Dich doch gedanktlich nicht einschränken, nur weil eine Entwicklungsumgebung dem Entwickler es durch Automatismen einfach(er) macht 😉