DB-First vs. Code First, welcher Weg ist besser geeignet für das Aufsetzen einer Web-App?
Eine Frage, die man sich häufig nicht nur zum Start eines Projektes stellt, sondern durchaus auch mitten in der Entwicklungsphase.
Unterschied zwischen DB-First vs. Code First
Wie der Name eventuell schon andeutet, handelt es sich bei DB-First um einen Datenbank getriebenen Ansatz. Heißt, die Datenbank wird zuerst modelliert und im Anschluss der Code darauf aufbauend erzeugt.
Beim Code-First Ansatz verläuft es genau umgekehrt. Hier werden die Entitäten zunächst im Code modelliert und aus dem Code heraus die Datenbank erzeugt.
Was ist besser?
Wie so oft gibt es hierzu keine immer gültige Antwort und hängt vor allem davon ab, ob die Anwendung eher datenbankgetrieben ist oder vor allem Business- und Anwendungsregeln beinhaltet.
Diese Frage lässt sich beantworten, in dem beobachtet wird, wo die Änderungen in der Regel stattfinden. Werden Änderungen überwiegend auf der Datenbankseite vorgenommen oder eher im Code?
Bei einfachen CRUD Anwendungen die einzig der Datenverwaltung dienen, kann es durchaus sein, dass die Änderungen nur auf Datenbankseite stattfinden, weil z.B. neue Spalten hinzukommen oder die Textlänge einer bestehenden Spalte verlängert werden soll.
Wenn es komplexer wird und die Technologieoffenheit bewahrt bleiben soll, ist in jedem Fall der Code-First Ansatz zu wählen. So kann eine SQL Datenbank zukünftig problemlos durch Oracle oder eine NoSQL Datenbank ausgetauscht werden und Entitäten zur Abbildung von Business Regeln genutzt werden.
Achtung: Wenn für komplexere Anwendungen, Code in der Datenbank über z.B. T-SQL Prozeduren erzeugt wird, wird der Code zunehmend schwieriger zu lesen (bzw. zu warten), fehleranfälliger (z.B. aufgrund von Typensicherheit) und die Entwicklungsdauer steigt mit jeder neuen Zeile SQL an.
T-SQL Prozeduren und Trigger sind nicht für die Modellierung von umfangreichen Anwendungen geeignet, in der es gilt, die Komplexität über verschiedene System Layer zu verteilen.
Code-First bietet im Vergleich zu DB-First die folgenden Vorteile:
- Technologieoffenheit (Keine bestimmte Datenbank notwendig)
- Nutzung von Entitäten bzw. Aggregaten in DDD zur Abbildung von Business- bzw. Domainregeln.
- Ungestörter Entwicklungsprozess. Die Anwendung kann ohne Rücksicht auf die Datenbank entwickelt werden und die Datenbank mit dem neuen Code aktualisiert werden, was zu einer flüssigeren und damit häufig produktiveren Entwicklung führt.
DB-First kann durch die folgenden Vorteile glänzen:
- Clientunabhängigkeit. Die Datenbank kann für unterschiedlichste Clients wiederverwendet werden und ist nicht an sie gebunden. So kann ein Datenbank Model als Code erzeugt und über eine Web-Schnittstelle für unterschiedlichste Clients zur Verfügung gestellt werden.
- Datensicherheit. Die Daten sind geschützt und werden separat verwaltet und nur über sichere, für die Datenbank vorgesehene Schnittstellen zugänglich gemacht. So kann das Risiko vor dem Verlust von wichtigen Daten reduziert werden.
- Hilfreich zur (initialen) Erzeugung eines Code-Models aus einem Legacy System heraus, bei dem bereits eine Datenbank besteht.
Verwendung von Code-First mit Entity Framework
Um eine Datenbank über Code zu erzeugen gibt es derzeit zwei Wege:
- Nutzung der EF-Core API
- Nutzung von Migrationen mit den dotnet Tools und der CLI
Je nach Entwicklungsstand macht der eine oder andere Weg mehr Sinn.
Während der Entwicklung wenn viele Änderungen erfolgen, kann der Einsatz der EF-Core API Sinn ergeben, in dem die komplette Datenbank gelöscht und wieder aufgebaut wird.
Nach dem die Anwendung in Produktion läuft, sollte vorwiegend auf Migrationen gesetzt werden, in dem nur noch Änderungen an der Datenbank eingespielt werden.
Verwendung von DB-First mit Entity Framework
Wenn DB-First genutzt werden soll, muss natürlich im Vorfeld die Datenbank modelliert werden. Im Anschluss kann aus der Datenbank einfach mit scaffolding, Anwendungscode erzeugt werden:
dotnet ef dbcontext scaffold "[DB_CONNECTION_STRING]" Microsoft.EntityFrameworkCore.SqlServer
