Déplacer d’EF6 vers EF Core

Entity Framework Core, ou EF Core pour un court terme, est une réécriture totale d’Entity Framework pour les architectures d’application modernes. En raison de changements fondamentaux, 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.

Raisons de la mise à niveau

Tout nouveau développement Entity Framework se produit dans EF Core. Aucune nouvelle fonctionnalité n’est prévue pour EF6. EF Core s’exécute sur les derniers runtimes .NET et tire pleinement parti des fonctionnalités spécifiques au runtime, propres à la plateforme (telles que ASP.NET Core ou WPF) et aux fonctionnalités propres 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 une réduction 40x de l’utilisation d’une requête lourde en raison de la fonctionnalité de fractionnement de requête. De nombreux clients signalent d’énormes gains de performances simplement en passant à la dernière version d’EF Core.
• Utilisez de 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 obtenir une comparaison complète d’EF6 à EF Core, notamment plusieurs fonctionnalités exclusives à EF Core, consultez : Comparer EF Core &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 en tant que 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. Prévoyez donc de commencer « 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 à l'avenir.

É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 » EF Core

Il existe plusieurs approches de 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é par le biais de code et de 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. Il s’agit souvent de « 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 à gérer avec le code à l’avenir.

La base de données comme source de vérité implique une ingénierie inverse ou une génération automatique 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 selon laquelle 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é :

L’approche hybride est une approche plus avancée avec une surcharge supplémentaire par rapport aux approches traditionnelles du code et de la 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 des schémas de domaine, de mappage et 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 affirment à tort qu'EF Core ne prend en charge que le modèle « code first ». 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 ef Core Power Tools open source qui fournit des fonctionnalités similaires pour EF Core.

Pour plus d'informations sur l'impact du manque de prise en charge des fichiers EDMX, lisez le guide porting EDMX.

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 EF6 dans la même application). Pour réduire les risques, vous pouvez envisager les éléments suivants :

1. Accédez à 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. Ensuite, apportez 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. Passez en revue les changements de comportement entre EF6 et EF Core.
2. Effectuez vos migrations finales, le cas échéant, dans EF6.
3. Créez votre projet EF Core.
4. Copiez du code dans le nouveau projet, exécutez l’ingénierie inverse ou une combinaison des deux.
5. Renommez les références et les entités et mettez à jour les comportements :
   • System.Data.Entity à Microsoft.EntityFrameworkCore
   • Modifier le constructeur DbContext pour consommer des options et/ou remplacer OnConfiguring
   • DbModelBuilder à ModelBuilder
   • Renommer DbEntityEntry<T> en EntityEntry<T>
   • Passer de Database.Log aux API Microsoft.Extensions.Logging (avancées) ou DbContextOptionsBuilder.LogTo (simples)
   • Appliquer les modifications pour WithRequired et WithOptional (voir ici)
   • Mettre à jour le code de validation. Il n’existe aucune validation des données intégrée à EF Core, mais vous pouvez le faire vous-même.
   • Suivez les étapes nécessaires pour transférer à partir d’EDMX.
6. Effectuez des étapes spécifiques en fonction de votre approche EF Core :
   • Code comme source de vérité
   • Base de données comme source de vérité
   • Modèle hybride

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