Wir schauen uns in diesem Post verschiedene Möglichkeiten an, um Daten mit EF core zu seeden. Das bedeutet unsere Datenbank mit initialen Startdaten zu versehen.
Warum möchten wir das Erreichen?
- Nutzerdaten / Usermanagement / Adminzugriff möglich machen
- Testdaten konsistent für neue Testsysteme bereitstellen
Die drei Möglichkeiten die wir uns ansehen sind:
Daten direkt definieren
EF core bietet die Möglichkeit unsere Startdaten direkt bei der Definition in der OnModelCreating Methode anzuwenden.
Dies geschieht im DbContext. Für weitere Infos siehe auch den Code first approach, dort wird erklärt, wie wir Entitäten und deren Beziehungen definieren können.
Dazu verwenden wir die HasData Methode. Wir schauen es hier am Beispiel der Product Entität an. Der Code dazu findet sich auf GitHub.
Da die Applikation bereits bestand, müssen wir eine Migration ausführen, um die geseedeten Daten zur Datenbank hinzuzufügen.
Dies schließt dann ebenfalls ein Datenbank update mit ein:
dotnet ef migrations add AddProductData -o ./Data/Migrations/
dotnet ef database update
Abfrage zum Start der Applikation
Eine zweite Möglichkeit ist es, die Startdaten durch Applikationscode einzufügen. Üblich ist es hier beim Start der Applikation auszuführen und diesem eine Abfrage voranzustellen.
Also in der Beispielapplikation ist dies die Program.cs Datei. In Asp.Net core wäre es z.B. die Startup Datei.
Wir erstellen hier erst eine Session mit der Datenbank durch das Instanziieren des LeantrainingDbContext.
Dann prüfen wir mit der Any Abfrage, ob es bereits eine Round Entität in der Datenbank gibt, welche den Primärschlüssel von 2 besitzt.
Ist dies nicht der Fall gehen wir ganz einfach nach der Methodik vor, die wir auch in CRUD Operationen mit EF core ansehen können.
Wir fügen die Round also dem Changetracking hinzu und committen es mit der SaveChanges Methode zur Datenbank.
Der Vorteil an dieser Methode ist, dass wir keine Migration anlegen und ausführen müssen.
Datenbankskript anlegen
Die dritte und letze Möglichkeit ist die eines herkömmlichen Skriptes für die Datenbank. Das hat mit EF core natürlich soweit nichts zu tun, ist aber der Vollständigkeit halber hier erwähnt.
Wie eine Skript auf der Datenbank angewendet wird hängt demnach natürlich vom Provider ab und ist bei einer Verwendung von EF core womöglich der umständlichste Weg.
0 Comments