Port d’EF6 vers EF Core - Base de données en tant que source de vérité

Si vous utilisez la base de données comme source de vérité, la mise à niveau implique principalement l’adressage des modifications apportées à la forme des entités générées. Les étapes de migration sont les suivantes :

1. Choisissez un point dans le temps pour modéliser la base de données.
2. Vérifiez que vos projets EF6 sont à jour et synchronisés avec la base de données.
3. Créez le projet EF Core.
4. Utilisez les outils de génération de modèles automatique pour inverser l’ingénierie de votre base de données en code.
5. Vérifiez que les classes générées par EF Core sont compatibles avec votre code.
6. Pour les exceptions, modifiez les classes générées et mettez à jour la configuration du modèle ou adaptez votre code au modèle.

Notez que bien qu’EF Core génère actuellement tout ce qui est nécessaire pour générer correctement une copie de la base de données, une grande partie du code n’est pas nécessaire pour l’approche base de données première. Un correctif pour cela est suivi dans problème #10890. Les éléments que vous pouvez ignorer en toute sécurité si nécessaire sont les séquences, les noms de contraintes, les index non uniques et les filtres d’index.

Gestion des modifications de schéma

Lorsque votre base de données est la source de la vérité, EF Core extrait les informations de schéma de la base de données plutôt que de les envoyer via des migrations. Le flux de travail classique consiste à réexécuter l’étape d’ingénierie inverse chaque fois que le schéma de base de données change. Une suite de tests complète est utile pour cette approche, car vous pouvez automatiser le processus de génération automatique et vérifier les modifications en exécutant vos tests.

Conseils pour la gestion des différences de modèle

Pour différentes raisons, vous souhaiterez peut-être que votre modèle de domaine C# soit mis en forme différemment de celui généré en ingénierie inverse. Dans de nombreux cas, cela signifie mettre à jour manuellement le code généré automatiquement après chaque modification de schéma. Une façon d’éviter un effort supplémentaire lorsque le code est régénéré consiste à utiliser des classes partielles pour vos entités DbContext et associées. Vous pouvez ensuite conserver le code lié à la logique métier et aux propriétés non suivies dans la base de données dans un ensemble distinct de fichiers de classe qui ne seront pas remplacés.

Si votre modèle est sensiblement différent de celui généré, mais ne change pas fréquemment, une option à prendre en compte est l’utilisation du modèle de référentiel en tant qu’adaptateur. Le référentiel peut consommer les classes générées PAR EF Core et publier les classes personnalisées que vous utilisez. Cela peut réduire l’impact des modifications en les isolant dans le code du référentiel, plutôt que d’avoir à effectuer une refactorisation à l’échelle de l’application chaque fois que le schéma change.

Vous pouvez envisager un autre flux de travail et suivre des étapes similaires à l’approche hybride. Au lieu de générer un nouvel ensemble de classes chaque fois, vous indiquez des tables spécifiques pour générer uniquement de nouvelles classes. Vous conservez les classes existantes « en l’état » et ajoutez ou supprimez directement des propriétés qui ont changé. Vous mettez ensuite à jour la configuration du modèle pour résoudre les modifications apportées à la façon dont la base de données est mappée à vos classes existantes.

Personnaliser la génération de code

EF Core 6 ne prend actuellement pas en charge la personnalisation du code généré. Il existe des solutions tierces telles que EF Core Power Tools disponibles. Pour obtenir la liste des outils et extensions de la communauté proposés, consultez : Outils et extensions EF Core.

Enfin, passez en revue la liste détaillée des différences entre EF6 et EF Core pour résoudre les problèmes restants liés au portage.