Migrationen sind ein entscheidender Teil von Entity Framework Core.

Prinzipiell werden mit mithilfe von Migrationen die erstellten C# POCOs und der DbContext in eine Datenbank überführt. Sie sind sozusagen die Übersetzung.

Wir haben auf der einen Seite jeweils den derzeitigen Stand der POCOs und des DbContextes und auf der anderen Seite den Stand der Migrationen, sowie die Datenbank.

Wir schauen uns also in diesem Post die verschiedenen Szenarien an in denen Migrationen zum Einsatz kommen.

POCOs & DbContext mit Migrationen in Migrationen in eine Db überführen

Migrationen - wie sie funktionieren

Migrationen werden immer mit dem CLI Tool erstellt. z.B. das hinzufügen einer Migration mit dem Namen MeineMigration.
dotnet ef migrations add MeineMigration -o /Data/Migrations
  • dotnet ef – dotnet ef cli tool
  • migrations – Migrationen command
  • MeineMigration – Name der Migration
  • -o /Data/Migrations/ – Directory der Migration
Wenn wir das ausführen sucht sich das CLI Tool folgendes aus dem aktuellen Verzeichnis oder seinen untergeordneten Verzeichnissen heraus:
  • POCOs
  • DbContext
  • evtl. bereits vorhandene Migrationsdateien
    am spezifizierten Directory

Mit diesen Daten gleicht das CLI Tool dann die Änderungen zwischen POCOs und DbContext und vorhandenen Migrationsdateien ab. Vom Konzept her ähnlich wie git die Versionskontrolle durchführt.

Dabei gibt es drei Szenarien:

  1. Migrationen repräsentieren den Zustand der POCOs und des DbContext (Keine Veränderungen)
  2. Keine Migrationen vorhanden (initiale Migration)
  3. Migrationen stellen einen anderen Zustand der POCOs dar (Veränderung)

Keine Veränderungen sind langweilig, und sollten auch keine Migration herbeiführen. deshalb schauen wir uns nur Fall 2 und 3 an.

Initiale Migration

Da noch keinerlei Daten vorhanden sind, kann hier nichts abgeglichen werden und es werden Migrationsdateien erzeugt. Dies sind drei an der Zahl:

  1. Migration.cs (Migration ist der MigrationsName)
  2. Migration.Designer.cs (Migration ist der MigrationsName)
  3. DbContextModelSnapshot.cs (DbContext mit deinem ContextName)

In der ersten Datei gibt es eine Up und eine Down Methode.

Die Up Methode dient dazu diese Änderungen auf die Datenbank zu übertragen.

Die Down Methode ist zum Rückführen (Revert) bzw. zurückrollen der Migration, falls etwas nicht nach Plan lief. Das schauen wir uns aber in einem gesonderten Post an.

In der Designer.cs Datei sind die Provider spezifischen Details der Migration zu finden. Also alles was dein NugetPaket für deinen EF Provider für deine Datenbank ausmachen. Also z.B. die Default Datentypen usw. usf.

In der ModelSnapshot.cs Datei finden wir die derzeitige Repräsentation des Models. Diese bezieht sich immer auf das zuletzt erstellte Model und wird nur bei der initialen Migration erzeugt und danach einfach nur überschrieben.

Das heißt nach der ersten Migration werden fortan immer nur 2 Dateien hinzugefügt.

Siehe hierfür auch im Github Repository die Migrationsfiles

Migrationsdateien der Initialen Migration im Github Repository zum Blog
Um mit diesen Migrationen nun eine Datenbank anzulegen, müssen wir folgendes Command ausführen:
dotnet ef database update
Siehe auch mehr dazu im Post über code-first.

Veränderung der Daten

Verändern wir nun die POCOs und den DbContext, z.B. wie im Post zum Thema SeedData, haben wir ein Mismatch zwischen Datenbank und unseren Entities. Demnach müssen wir nun eine Migration durchführen, damit unsere Applikation weiterhin funktioniert.

Auch das tun wir erneut über das gleiche Verfahren (wie oben beschrieben)

Das CLI Tool erstellt uns dann zwei neue Migrations dateien (Migration.cs und Migration.Designer.cs) die mit dem Datum und Namen unserer Migration geprefixt sind.

Wie wir sehen können gibt es aber immernoch nur eine DbContextModelSnapshot Datei.

Mit erneutem Anwenden auf der Datenbank, erhalten wir eine erneute Synchronisierung der Applikation und der Datenbank.

Migrationsdateien nach Änderungen an den POCOs

.

3 Wege um Migrationen auf der Datenbank anzuwenden

Migrationen an sich erstellen/verändern die vorhandene Datenbank noch nicht, sondern sind nur eine Vorlage.

Um die Datenbank endgültig anzupassen, benötigen wir eine Anwendung der Migration. Dafür gibt es 3 Möglichkeiten:

  1. Per SQL Skrip
    •  Wir können aus den erstellten Migrationen ein SQL Skript erzeugen. Dieses kann dann auf dem normalen Wege auf der Datenbank angewendet werden:
      dotnet ef migrations script 

      Dies erstellt ein Skript, dass alle vorhandenen Migrationen einebezieht. Möchte man nur einen bestimmten Zustand, kann man FROM und TO spezifizieren (MigrationsNamen)

  2. Per CLI Tool

    • Der üblichste Weg ist wohl der über das CLI Tool. Hier verwenden wir aber nicht das migrations commands, sondern das database update command.
  3. Per Code

    • Eine dritte Möglichkeit ist die Extension Method auf der DbContext.Database Facade.
      Diese ist passenderweise Migrate/MigrateAsync betitelt und im Namensraum Microsoft.EntityFrameworkCore zu finden
Categories: ef-core-de

0 Comments

Leave a Reply

Avatar placeholder