Partager via

Cas détaillés pour le portage d’EF6 vers EF Core

  • Article

Ce document détaille certaines différences spécifiques entre EF6 et EF Core. Consultez ce guide lors du portage de votre code.

Configuration de la connexion de base de données

Il existe plusieurs différences entre la façon dont EF6 se connecte à différentes sources de données par rapport à EF Core. Il est important de comprendre quand vous transférez votre code.

  • Chaînes de connexion: EF Core ne prend pas directement en charge plusieurs surcharges de constructeur pour différentes chaînes de connexion comme EF6. Au lieu de cela, elle s’appuie sur DbContextOptions. Vous pouvez toujours fournir plusieurs surcharges de constructeur dans les types dérivés, mais vous devez mapper les connexions via les options.
  • Configuration et mise en cache: EF Core prend en charge une implémentation plus robuste et flexible de l’injection de dépendances avec une infrastructure interne qui peut se connecter à des fournisseurs de services externes. Cela peut être géré par l’application pour gérer les situations où les caches doivent être vidés. La version EF6 était limitée et ne pouvait pas être vidée.
  • Fichiers de configuration: EF6 prend en charge la configuration via des fichiers de configuration pouvant inclure le fournisseur. EF Core nécessite une référence directe à l’assembly du fournisseur et à l’inscription explicite du fournisseur (par exemple, UseSqlServer).
  • Fabriques de connexion: fabriques de connexions prises en charge par EF6. EF Core ne prend pas en charge les fabriques de connexion et nécessite toujours une chaîne de connexion.
  • journalisation : en général, journalisation dans EF Core est beaucoup plus robuste et dispose de plusieurs options pour une configuration affinée.

Conventions

Conventions personnalisées (« légères ») prises en charge par EF6 et conventions de modèle. Les conventions légères sont similaires à la configuration de modèle de pré-convention d’EF Core. D’autres conventions sont prises en charge dans le cadre de la génération de modèles.

EF6 exécute des conventions après la génération du modèle. EF Core les applique à mesure que le modèle est généré. Dans EF Core, vous pouvez dissocier la génération de modèles à partir de sessions actives avec un DbContext. Il est possible de créer un modèle initialisé avec les conventions.

Validation des données

EF Core ne prend pas en charge la validation des données et utilise uniquement les annotations de données pour créer le modèle et les migrations. La plupart des bibliothèques clientes du web/MVC vers WinForms et WPF fournissent une implémentation de validation des données à utiliser.

Fonctionnalités bientôt disponibles

Il existe quelques fonctionnalités dans EF6 qui n’existent pas encore dans EF Core, mais qui se trouvent sur la feuille de route du produit.

  • Type table par béton (TPC) a été pris en charge dans EF6, ainsi que le « fractionnement d’entité » TPC est sur la feuille de route pour EF7.
  • Mappage de procédure stockée dans EF6 vous permet de déléguer des opérations de création, de mise à jour et de suppression à des procédures stockées. EF Core autorise actuellement uniquement le mappage aux procédures stockées pour les lectures. La prise en charge de la création, de la mise à jour et de la suppression (CUD) se trouve sur la feuille de route d’EF7.
  • Types complexes dans EF6 sont similaires aux types détenus dans EF Core. Toutefois, l’ensemble complet de fonctionnalités sera traité avec des objets valeur dans EF7.

Laisser ObjectContext derrière

EF Core utilise un DbContext au lieu d’un ObjectContext. Vous devrez mettre à jour le code qui utilise IObjectContextAdapter. Cela a parfois été utilisé pour les requêtes avec une option de fusion PreserveChanges ou OverwriteChanges. Pour obtenir des fonctionnalités similaires dans EF Core, examinez la méthode de rechargement .

Configuration du modèle

Il existe de nombreuses différences importantes entre la façon dont les modèles dans EF6 et EF Core sont conçus. EF Core n’a pas de prise en charge complète du mappage conditionnel. Il n’a pas de versions du générateur de modèles.

D’autres différences sont les suivantes :

Découverte du type

Dans EF Core, les types d’entités sont découverts par le moteur de trois façons :

  • Exposez une DbSet<TEntity> sur votre DbContext où TEntity est le type que vous souhaitez suivre.
  • Référencez une Set<TEntity> de quelque part dans votre code.
  • Les types complexes référencés par les types découverts sont découverts de manière récursive (par exemple, si votre Blog référence un Post et que Blog est détectable, Post seront également découverts)

Les assemblys ne sont pas analysés pour les types dérivés.

Mappage

L’extension .Map() dans EF6 a été remplacée par des surcharges et des méthodes d’extension dans EF Core. Par exemple, vous pouvez utiliser « . HasDiscriminator() pour configurer la table par hiérarchie (TPH). Voir : Héritage de modélisation.

Mappage d’héritage

EF6 prend en charge la table par hiérarchie (TPH), la table par type (TPT) et la classe de table par béton (TPC) et le mappage hybride activé de différentes saveurs à différents niveaux de la hiérarchie. EF Core continuera à exiger une chaîne d’héritage modélisée de manière unique (TPT ou TPH) et le plan consiste à ajouter la prise en charge du TPC dans EF7.

Voir : Héritage de modélisation.

Attributs

Attributs d’index pris en charge par EF6 sur les propriétés. Dans EF Core, ils sont appliqués au niveau du type, ce qui devrait faciliter les scénarios nécessitant des index composites. EF Core ne prend pas en charge les clés composites avec des annotations de données (c’est-à-dire l’utilisation de Order dans ColumnAttribute avec KeyAttribute).

Pour plus d’informations, consultez : Index et contraintes.

Obligatoire et facultatif

Dans la génération de modèles EF Core, IsRequired configure uniquement les éléments requis à la fin du principal. HasForeignKey configure maintenant la fin du principal. Pour porter votre code, il sera plus simple d’utiliser .Navigation().IsRequired() à la place. Par exemple :

EF6.4 :

modelBuilder.Entity<Instructor>()
    .HasRequired(t => t.OfficeAssignment)
    .WithRequiredPrincipal(t => t.Instructor);

EF Core 6:

modelBuilder.Entity<Instructor>()
    .HasOne(t => t.OfficeAssignment)
    .WithOne(t => t.Instructor)
    .HasForeignKey<OfficeAssignment>();

modelBuilder.Entity<Instructor>()
    .Navigation(t => t.OfficeAssignment)
    .IsRequired();

modelBuilder.Entity<OfficeAssignment>()
    .Navigation(t => t.Instructor)
    .IsRequired();

Par défaut, tout est facultatif. En général, il n’est pas nécessaire d’appeler .IsRequired(false).

Prise en charge spatiale

EF Core s’intègre à la bibliothèque de bibliothèques tierces NetTopologySuite pour fournir une prise en charge spatiale.

Associations indépendantes

EF Core ne prend pas en charge les associations indépendantes (concept EDM qui permet de définir la relation entre deux entités indépendamment des entités elles-mêmes). Un concept similaire pris en charge dans EF Core est propriétés d’ombre.

Migrations

EF Core ne prend pas en charge les initialiseurs de base de données ni les migrations automatiques. Bien qu’il n’existe aucun migrate.exe dans EF Core, vous pouvez produire des offres groupées de migration.

Outils Visual Studio

EF Core n’a pas de concepteur, aucune fonctionnalité pour mettre à jour le modèle à partir de la base de données et aucun flux model-first. Il n’existe aucun Assistant d’ingénierie inverse et aucun modèle intégré.

Bien que ces fonctionnalités ne soient pas fournies avec EF Core, il existe des projets de communauté OSS qui fournissent des outils supplémentaires. Plus précisément, EF Core Power Tools fournit les éléments suivants :

  • Ingénierie inversée à partir de Visual Studio avec prise en charge des projets de base de données (.dacpac). Inclut des personnalisations de code basées sur des modèles.
  • Inspection visuelle de DbContext avec le graphe de modèle et le script.
  • Gestion des migrations à partir de Visual Studio à l’aide d’une interface graphique utilisateur.

Pour obtenir la liste complète des outils et extensions de la communauté, consultez : Outils et extensions EF Core.

Suivi des modifications

Il existe plusieurs différences entre la façon dont EF6 et EF Core traitent le suivi des modifications. Ceux-ci sont résumés dans le tableau ci-après :

Fonctionnalité EF6 EF Core
État d’entité Ajoute/attache l’intégralité du graphique Prend en charge les navigations vers des entités détachées
Orphelins Préservé Supprimé
Entités déconnectées et auto-suivi Pris en charge Non pris en charge
Mutations Effectué sur les propriétés Effectué sur les champs de stockage*
Liaison de données .Local .Local plus .ToObservableCollection ou .ToBindingList
Détection des changements Graphique complet Par entité

* Par défaut, la notification de propriété ne sera pas déclenchée dans EF Core. Il est donc important de configurer des entités de notification.

Notez qu’EF Core n’appelle pas automatiquement la détection des modifications autant que EF6.

EF Core présente une DebugView détaillée pour le suivi des modifications. Pour plus d’informations, lisez Débogage du dispositif de suivi des modifications.

Requêtes

EF6 possède certaines fonctionnalités de requête qui n’existent pas dans EF Core. Il s’agit notamment des paramètres suivants :

  • Certaines fonctions C# courantes et mappages de fonctions SQL.
  • Interception de l’arborescence de commandes pour les requêtes et les mises à jour.
  • Prise en charge des paramètres table (TVP).

EF6 prend en charge les proxys de chargement différé. Il s’agit d’un package d’adhésion pour EF Core (consultez Chargement différé de données associées).

EF Core vous permet de composer sur SQL brut à l’aide de FromSQL.