Portieren von EF6 zu EF Core – Datenbank als Source of Truth (SOT)

Wenn Sie die Datenbank als Source of Truth (SOT) verwenden, umfasst das Upgrade hauptsächlich alle Änderungen an der Form der generierten Entitäten. Zu den Migrationsschritten gehören:

  1. Wählen Sie einen Zeitpunkt für die Datenbankmodellierung.
  2. Stellen Sie sicher, dass Ihre EF6-Projekte auf dem neuesten Stand und mit der Datenbank synchronisiert sind.
  3. Erstellen Sie das EF Core-Projekt.
  4. Verwenden Sie die Gerüstbautools, um ein Reverse Engineering Ihrer Datenbank in Code vorzunehmen.
  5. Überprüfen Sie, ob die von EF Core generierten Klassen mit Ihrem Code kompatibel sind.
  6. Ändern Sie bei Ausnahmen entweder die generierten Klassen, und aktualisieren Sie die Modellkonfiguration, oder passen Sie Ihren Code an das Modell an.

Beachten Sie, dass EF Core derzeit zwar alles erstellt, was zum erfolgreichen Generieren einer Kopie der Datenbank erforderlich ist, ein Großteil des Codes jedoch für den Database-First-Ansatz nicht benötigt wird. Ein Fix dafür wird in Problem Nr. 10890 nachverfolgt. Zu den Dingen, die Sie als nicht erforderlich ignorieren können, zählen Sequenzen, Einschränkungsnamen, nicht eindeutige Indizes und Indexfilter.

Behandeln von Schemaänderungen

Wenn Ihre Datenbank die Source of Truth (SOT) ist, ruft EF Core Schemainformationen aus der Datenbank ab, anstatt sie über Migrationen zu pushen. Der typische Workflow besteht darin, den Reverse Engineering-Schritt bei jeder Änderung des Datenbankschemas erneut auszuführen. Eine umfassende Testsammlung ist für diesen Ansatz nützlich, da Sie den Gerüstbauprozess automatisieren und die Änderungen überprüfen können, indem Sie Ihre Tests ausführen.

Tipps zum Behandeln von Modellunterschieden

Es gibt verschiedene Gründe, warum Sie möchten, dass Ihr C#-Domänenmodell anders gestaltet werden soll als das Modell, das im Reverse Engineering generiert wurde. In vielen Fällen bedeutet dies, dass der Code, der nach jeder Schemaänderung automatisch generiert wird, manuell aktualisiert wird. Eine Möglichkeit, zusätzlichen Aufwand zu vermeiden, wenn der Code neu generiert wird, besteht darin, partielle Klassen für Ihre DbContext-Entität und zugehörigen Entitäten zu verwenden. Anschließend können Sie Code im Zusammenhang mit Geschäftslogik und Eigenschaften, die nicht in der Datenbank nachverfolgt werden, in einer separaten Gruppe von Klassendateien beibehalten, die nicht überschrieben werden.

Wenn sich Ihr Modell erheblich von dem generierten Modell unterscheidet, sich jedoch nicht häufig ändert, sollten Sie das Repositorymuster als Adapter verwenden. Das Repository kann die von EF Core generierten Klassen nutzen und die von Ihnen verwendeten benutzerdefinierten Klassen veröffentlichen. Dies kann die Auswirkungen von Änderungen verringern, indem sie im Repositorycode isoliert werden, anstatt bei jeder Schemaänderung ein anwendungsweites Refactoring durchführen zu müssen.

Möglicherweise sollten Sie einen alternativen Workflow in Betracht ziehen und die Schritte ausführen, die dem hybriden Ansatz ähneln. Anstatt jedes Mal einen neuen Satz von Klassen zu generieren, geben Sie bestimmte Tabellen an, um nur neue Klassen zu generieren. Sie behalten vorhandene Klassen unverändert bei und fügen Eigenschaften, die sich geändert haben, direkt hinzu oder entfernen sie. Anschließend aktualisieren Sie die Modellkonfiguration, um alle Änderungen in der Zuordnung der Datenbank zu Ihren vorhandenen Klassen zu berücksichtigen.

Anpassen der Codegenerierung

EF Core 6 unterstützt derzeit keine Anpassung des generierten Codes. Es gibt Lösungen von Drittanbietern wie EF Core Power Tools. Eine Liste der empfohlenen Communitytools und -erweiterungen finden Sie unter EF Core-Tools und Erweiterungen.

Überprüfen Sie abschließend die detaillierte Liste der Unterschiede zwischen EF6 und EF Core, um alle verbleibenden Probleme mit der Portierung zu beheben.