Partager via

Déplacer d’EF6 vers EF Core

  • Article

Entity Framework Core, ou EF Core pour un court terme, est une réécriture totale d’Entity Framework pour les architectures d’applications modernes. En raison des modifications fondamentales, il n’existe pas de chemin de mise à niveau directe. L’objectif de cette documentation est de fournir un guide de bout en bout pour le portage de vos applications EF6 vers EF Core.

Important

Avant de commencer le processus de portage, il est important de vérifier qu’EF Core répond aux exigences d’accès aux données de votre application. Vous trouverez tout ce dont vous avez besoin dans la documentation EF Core.

Important

Il existe un problème connu (microsoft/dotnet-apiport #993) avec l’analyseur de portabilité qui signale par erreur EF Core comme incompatible avec .NET 5 et .NET 6. Ces avertissements peuvent être ignorés en toute sécurité, car EF Core est entièrement compatible avec les frameworks cibles .NET 5 et .NET 6.

Raisons d'une mise à jour

Tout nouveau développement Entity Framework se produit dans EF Core. Il n’existe aucun plan de rétroporter les nouvelles fonctionnalités vers EF6. EF Core s’exécute sur les derniers runtimes .NET et tire pleinement parti des fonctionnalités spécifiques au runtime, à la plateforme (par exemple, ASP.NET Core ou WPF) et aux fonctionnalités spécifiques au langage. Voici quelques-uns des avantages que vous bénéficiez de la mise à niveau :

  • Tirez parti des améliorations continues des performances dans EF Core. Par exemple, un client qui a migré d’EF6 vers EF Core 6 a vu l’utilisation d’une requête lourde être quarante fois moins fréquente en raison de la fonctionnalité de fractionnement des requêtes. De nombreux clients signalent d’énormes gains de performances simplement en passant à la dernière version d’EF Core.
  • Utilisez les nouvelles fonctionnalités dans EF Core. Aucune nouvelle fonctionnalité n’est ajoutée à EF6. Toutes les nouvelles fonctionnalités, par exemple le fournisseur Azure Cosmos DB et DbContextFactory, ne seront ajoutées qu’à EF Core. Pour une comparaison complète entre EF6 et EF Core, y compris plusieurs fonctionnalités exclusives à EF Core, consultez : Comparer EF Core et EF6.
  • Moderniser votre pile d’applications à l’aide de l’injection de dépendances et intégrer en toute transparence votre accès aux données avec des technologies telles que gRPC et GraphQL.

Remarque sur les migrations

Cette documentation utilise les termes port et mise à niveau pour éviter toute confusion avec le terme migrations comme fonctionnalité d’EF Core. Les migrations dans EF Core ne sont pas compatibles avec les migrations EF6 Code First en raison d’améliorations significatives de la façon dont les migrations sont gérées. Il n’existe pas d’approche recommandée pour porter votre historique des migrations, donc prévoyez de démarrer « frais » dans EF Core. Vous pouvez gérer la base de code et les données de vos migrations EF6. Appliquez votre migration finale dans EF6, puis créez une migration initiale dans EF Core. Vous pourrez suivre l’historique dans EF Core.

Étapes de la mise à niveau

Le chemin de mise à niveau a été divisé en plusieurs documents organisés par la phase de votre mise à niveau et le type d’application.

Déterminer votre « saveur » d’EF Core

Il existe plusieurs approches pour l’utilisation d’EF Core avec votre modèle de domaine et votre implémentation de base de données. En général, la plupart des applications suivent l’un de ces modèles et la façon dont vous approchez votre port dépend de la « saveur » de l’application.

Le code comme source de vérité est une approche dans laquelle tout est modélisé via du code et des classes, qu’il s’agisse d’attributs de données, de configuration fluent ou d’une combinaison des deux. La base de données est initialement générée en fonction du modèle défini dans EF Core et d’autres mises à jour sont généralement gérées par le biais de migrations. Cela est souvent appelé « code d’abord », mais le nom n’est pas entièrement précis, car une approche consiste à commencer par une base de données existante, à générer vos entités, puis à maintenir avec le code en avance.

La base de données comme source de vérité implique l’ingénierie inverse ou la génération de votre code à partir de la base de données. Lorsque des modifications de schéma sont apportées, le code est régénéré ou mis à jour pour refléter les modifications. Il s’agit souvent de « base de données en premier »

Enfin, une approche de mappage hybride plus avancée suit la philosophie que le code et la base de données sont gérés séparément, et EF Core est utilisé pour mapper entre les deux. Cette approche évite généralement les migrations.

Le tableau suivant récapitule quelques différences de niveau élevé :

Approche Rôle du développeur Rôle DBA Migrations Génération de modèles automatique Référentiel
Code first Concevoir des entités et vérifier/personnaliser les migrations générées Vérifier les définitions et les modifications du schéma Par validation S.O. Suivre les entités, DbContext et migrations
Database first Ingénieur inverse après les modifications et vérification des entités générées Informer les développeurs lorsque la base de données change de structure S.O. Par modification de schéma Suivre les extensions/classes partielles qui étendent les entités générées
Hybride Mettre à jour la configuration fluent pour mapper chaque fois que les entités ou les modifications de base de données Informer les développeurs quand la base de données a changé afin qu’elles puissent mettre à jour les entités et la configuration du modèle N/A N/A Suivre les entités et DbContext

L’approche hybride est une approche plus avancée avec une surcharge supplémentaire par rapport aux approches traditionnelles de code et de base de données.

Comprendre l’impact du déplacement d’EDMX

EF6 a pris en charge un format de définition de modèle spécial nommé Entity Data Model XML (EDMX). Les fichiers EDMX contiennent plusieurs définitions, notamment des définitions de schéma conceptuel (CSDL), des spécifications de mappage (MSL) et des définitions de schéma (SSDL). EF Core effectue le suivi du domaine, du mappage et des schémas de base de données via des graphiques de modèles internes et ne prend pas en charge le format EDMX. De nombreux billets de blog et articles par erreur indiquent cela signifie qu’EF Core prend uniquement en charge « code d’abord ». EF Core prend en charge les trois modèles d’application décrits dans la section précédente. Vous pouvez reconstruire le modèle dans EF Core en ingénierie inverse de la base de données. Si vous utilisez EDMX pour une représentation visuelle de votre modèle d’entité, envisagez d’utiliser les open source EF Core Power Tools qui fournissent des fonctionnalités similaires pour EF Core.

Pour plus d’informations sur l’impact de l’absence de prise en charge des fichiers EDMX, consultez le guide EDMX de portage.

Effectuer les étapes de mise à niveau

Il n’est pas nécessaire de porter l’ensemble de l’application. EF6 et EF Core peuvent s’exécuter dans la même application (voir : Utilisation d’EF Core et d’EF6 dans la même application). Pour réduire les risques, vous pouvez envisager les éléments suivants :

  1. Passez à EF6 sur .NET Core si vous ne l’avez pas déjà fait.
  2. Migrez une petite partie de votre application vers EF Core et exécutez-la côte à côte avec EF6.
  3. Apportez finalement le reste de la base de code à EF Core et retirez le code EF6.

Quant au port lui-même, à un niveau élevé, vous allez :

  1. Passer en revue les changements de comportement entre EF6 et EF Core.
  2. Effectuer vos migrations finales, le cas échéant, dans EF6.
  3. Créer votre projet EF Core.
  4. Copier du code dans le nouveau projet, exécuter l’ingénierie inverse ou une combinaison des deux.
  5. Renommez les références et les entités et les comportements de mise à jour :
    • Il lance System.Data.Entity sur Microsoft.EntityFrameworkCore.
    • Modifier le constructeur DbContext pour consommer des options et/ou remplacer OnConfiguring
    • Il lance DbModelBuilder sur ModelBuilder.
    • Renommer DbEntityEntry<T> par EntityEntry<T>
    • Passer des API Database.Log à Microsoft.Extensions.Logging (avancées) ou DbContextOptionsBuilder.LogTo (simples)
    • Appliquer les modifications pour WithRequired et WithOptional (voir ici)
    • Mettre à jour le code de validation. Aucune validation des données n’est intégrée à EF Core, mais vous pouvez la faire vous-même.
    • Suivez les étapes nécessaires pour porter à partir d’EDMX.
  6. Effectuez des étapes spécifiques en fonction de votre approche EF Core :

Il existe de nombreuses considérations relatives à toutes les approches. Vous voudrez donc également examiner les façons de résoudre et de contourner les différences détaillées entre EF6 et EF Core.