Planifier Entity Framework Core 7.0

Comme décrit dans le processus de planification, nous avons recueilli les commentaires des parties prenantes dans un plan pour Entity Framework Core 7.0 (EF Core 7.0.) Par souci de concision, EF Core 7.0 est également appelé EF7.

Important

Ce plan ne constitue pas un engagement ; il évoluera au fur et à mesure des enseignements que nous tirerons tout au long du développement de la version. Par exemple, certaines choses qui ne sont pas actuellement prévues pour EF7 pourront être intégrées. Inversement, certaines choses actuellement prévues pour EF7 pourront être annulées.

Informations générales

EF Core 7.0 est la version qui fait suite à EF Core 6.0. Sa publication est actuellement prévue pour novembre 2022, en même temps que .NET 7. Aucune version 6.1 d’EF Core n’est prévue.

Plateformes prises en charge

EF7 cible actuellement .NET 6. Nous passerons peut-être à .NET 7 à l’approche de la date de publication. EF7 ne cible aucune version de .NET Standard. Pour plus d’informations, consultez L’avenir de .NET Standard. EF7 ne s’exécutera pas sur le .NET Framework.

EF7 s’alignera sur la stratégie de support .NET et ne sera donc pas une version bénéficiant d’un support à long terme (LTS).

Dernières modifications

EF7 contiendra un petit nombre de changements cassants à mesure que nous continuerons à faire évoluer EF Core et la plateforme .NET. Notre objectif est de réduire autant que possible les changements cassants.

Thèmes

Les grands investissements dans EF7 seront principalement axés sur les thèmes suivants :

  • Fonctionnalités très demandées
  • Plateformes et écosystème NET
  • Voie claire à suivre à partir d’EF6
  • Performances

Chacun de ces thèmes est décrit en détail ci-dessous. Vous pouvez suivre l’état général de chaque thème dans les mises à jour bihebdomadaires d’EF Core. Veuillez ajouter vos commentaires ou suggestions au problème GitHub n° 26994.

Thème : fonctionnalités très demandées

Comme toujours, les votes (👍) exprimés pour les fonctionnalités sur GitHub ont une influence majeure sur le processus de planification. En fonction de ces votes et d’autres facteurs, voici les fonctionnalités très demandées pour EF7 sur lesquelles nous prévoyons de travailler.

Colonnes JSON

Suivi : Problème n° 4021 : mapper des valeurs JSON stockées dans une base de données à des propriétés EF

Proposition de valeur : enregistrer et interroger des documents JSON stockés dans des colonnes de base de données relationnelle.

Cette fonctionnalité introduira un mécanisme et des modèles courants pour la prise en charge de JSON qui pourront être implémentés par n’importe quel fournisseur de base de données. Nous collaborerons avec la communauté pour aligner les implémentations existantes pour Npgsql et Pomelo MySQL, et ajouterons également la prise en charge de SQL Server et de SQLite.

Mises à jour en bloc

Suivi : Problème n° 795 : opérations CUD en bloc (c’est-à-dire basées sur un ensemble) sans charger de données en mémoire

Proposition de valeur : mises à jour efficaces basées sur des prédicats pour de nombreuses lignes de base de données sans charger de données en mémoire.

Le suivi des modifications suivi de SaveChanges est le principal mécanisme d’EF Core pour l’insertion, la mise à jour et la suppression d’entités. Ce mécanisme garantit que les opérations de base de données sont ordonnées pour satisfaire aux contraintes et que les entités suivies sont synchronisées avec les modifications apportées à la base de données. Toutefois, il nécessite un aller-retour dans la base de données pour charger les entités en mémoire afin de créer les commandes de base de données appropriées, puis un aller-retour dans la base de données pour exécuter ces commandes.

En revanche, les mises à jour en bloc ou basées sur un ensemble impliquent la définition des modifications à apporter à la base de données, puis l’exécution de ces modifications sans charger au préalable les entités en mémoire. Ce processus peut être beaucoup plus rapide que les mises à jour suivies, en particulier quand la même modification doit être appliquée à de nombreuses entités/lignes différentes.

Pour EF7, nous prévoyons d’implémenter des mises à jour et des suppressions en bloc (mais pas d’insertions). Notez que les mises à jour en bloc et les mises à jour par lot sont deux choses différentes. EF Core combine déjà les modifications apportées à de nombreuses entités suivies en lots lors de l’envoi de mises à jour à la base de données par le biais de SaveChanges.

Hooks de cycle de vie

Suivi : Problème n° 626 : crochets de cycle de vie

Proposition de valeur : autoriser les applications à réagir lorsque des choses intéressantes se produisent dans le code EF.

Les crochets de cycle de vie permettent de notifier une application ou une bibliothèque chaque fois que certaines conditions ou actions intéressantes se produisent en rapport avec des entités, des propriétés, des relations, des requêtes, des instances de contexte et d’autres constructions EF. Nous avons implémenté de nombreux crochets de cycle de vie sur les versions précédentes d’EF Core, notamment divers intercepteurs et événements. Pour EF7, nous prévoyons d’ajouter des crochets manquants importants. Par exemple, nous envisageons d’ajouter un crochet pour la manipulation des instances d’entité après leur création (événement communément appelé ObjectMaterialized).

Mappage de table par type concret (TPC)

Suivi : Problème n° 3170 : modèle de mappage d’héritage TPC

Proposition de valeur : mapper les entités d’une hiérarchie à des tables distinctes sans subir la réduction des performances associée au mappage TPT.

EF Core prend en charge le mappage de table par hiérarchie (TPH) et de table par type (TPT) pour les hiérarchies d’héritage .NET. Le mappage de table par type concret (TPC) est similaire au mappage TPT dans le sens où chaque type d’entité dans la hiérarchie est mappé à une table de base de données différente. Toutefois, alors que TPT mappe les propriétés d’un type de base aux colonnes d’une table pour le type de base, TPC mappe les propriétés du type de base à la même table que le type concret réel mappé. Étant donné qu’il n’est pas nécessaire de joindre plusieurs tables lors de l’interrogation d’un type spécifique, les performances peuvent s’en trouver considérablement améliorées. Cela se fait au détriment de la dénormalisation des données, les colonnes étant dupliquées dans les tables mappées à chaque type concret de la hiérarchie.

Le travail de mappage TPC couvre également le fractionnement d’entité plus général et la prise en charge de la spécification de différentes facettes par table dans TPT, TPC ou le fractionnement d’entité.

Mapper les opérations CUD à des procédures stockées

Suivi : Problème n° 245 : mapper les insertions, mises à jour et suppressions (opérations CUD) à des procédures stockées

Proposition de valeur : utiliser des procédures stockées pour gérer les modifications de données.

EF Core prend déjà en charge l’interrogation des données à partir de procédures stockées. Cette fonctionnalité permettra de mapper les insertions, mises à jour et suppressions générées par SaveChanges à des procédures stockées dans la base de données.

Objets de valeur

Suivi : Problème n° 9906 : utiliser des structs ou des classes C# comme objets de valeur

Proposition de valeur : les applications peuvent utiliser des objets de valeur de style DDD dans les modèles EF.

Auparavant, l’équipe considérait que les entités détenues, destinées à la prise en charge d’agrégation, constituaient également une approximation raisonnable des objets de valeur. L’expérience a montré que ce n’est pas le cas. Par conséquent, dans EF7, nous prévoyons d’introduire une meilleure expérience axée sur les besoins des objets de valeur dans la conception pilotée par le domaine. Cette approche sera basée sur des convertisseurs de valeurs plutôt que sur des entités détenues.

Ce travail est initialement limité à l’autorisation de convertisseurs de valeurs mappés à plusieurs colonnes. Nous ajouterons peut-être une prise en charge supplémentaire en fonction des commentaires reçus lors de la publication.

Prise en charge de la génération de valeurs lors de l’utilisation de convertisseurs de valeurs

Suivi : Problème n° 11597 : prendre en charge davantage de types de génération de valeur avec des convertisseurs

Proposition de valeur : les types de clés encapsulés de style DDD peuvent exploiter pleinement les valeurs de clé générées automatiquement.

EF Core 6.0 a permis d’utiliser davantage de types de génération de valeurs avec des clés mappées par le biais de convertisseurs de valeurs. Nous prévoyons de généraliser et d’étendre cette prise en charge dans EF7.

Requêtes SQL brutes pour les types non mappés

Suivi : Problème n° 10753 : prendre en charge les requêtes SQL brutes sans définir de type d’entité pour le résultat

Proposition de valeur : les applications peuvent exécuter davantage de types de requêtes SQL brutes sans passer à ADO.NET ni utiliser de bibliothèques tierces.

Actuellement, les requêtes SQL brutes doivent retourner un type dans le modèle, avec ou sans clé définie. Dans EF7, nous prévoyons d’autoriser les requêtes SQL brutes qui retournent directement des types qui ne sont pas contenus dans le modèle EF.

Le travail ici couvrira également les requêtes SQL brutes qui retournent des types simples/scalaires comme Guid, DateTime, int et string.

Modèles de génération de modèles automatique de base de données

Suivi : Problème n° 4038 : modèles de code pour les types d’entités de génération de modèles automatique et DbContext à partir d’une base de données existante

Proposition de valeur : le code généré par dotnet ef database scaffold peut être entièrement personnalisé.

Nous recevons fréquemment des demandes pour ajuster le code généré lors de la génération de modèles automatique (ingénierie à rebours) à partir d’une base de données existante. Nous prévoyons de traiter ces demandes dans EF7 en prenant en charge les modèles T4 pour les types d’entités générés et DbContext. Les développeurs pourront personnaliser les modèles standard ou créer des modèles à partir de zéro.

Thème : plateformes et écosystème .NET

Une grande partie du travail prévu pour EF7 consiste à améliorer l’expérience d’accès aux données pour .NET sur différents domaines et plateformes. Cela implique de travailler dans EF Core si nécessaire, mais également dans d’autres domaines pour garantir une bonne expérience dans les technologies .NET. Pour EF7, nous nous concentrerons sur les plateformes/technologies suivantes :

Cette liste est basée sur de nombreux facteurs, notamment les données client, l’orientation stratégique et les ressources disponibles. Les domaines généraux sur lesquels nous travaillerons pour ces plateformes sont décrits ci-dessous.

Transactions distribuées

Suivi : Problème n° 715 dans dotnet/runtime : implémenter des transactions distribuées/promues dans System.Transactions

Proposition de valeur : les applications .NET Framework utilisant des transactions distribuées peuvent être déplacées vers .NET 7.

La bibliothèque System.Transactions du .NET Framework contient du code natif qui utilise le coordinateur de transactions distribuées (DTC) de Windows pour prendre en charge les transactions distribuées. Ce code n’a jamais été déplacé vers .NET Core. Dans le cadre de .NET 7, nous prévoyons d’examiner et de commencer le processus visant à intégrer cette fonctionnalité à la version moderne de .NET. Nous nous concentrerons initialement sur Windows et prendrons uniquement en charge les scénarios de base de données où le fournisseur ADO.NET prend également en charge les transactions distribuées. D’autres utilisations des transactions distribuées, comme dans WCF, ne seront pas prises en charge dans .NET 7. En fonction des commentaires et des coûts, nous implémenterons peut-être la prise en charge d’autres scénarios et/ou plateformes non-Windows dans une prochaine version.

Outils EF Core

Suivi : Problème n° 26798 : moderniser les outils EF Core

Proposition de valeur : les commandes dotnet ef sont faciles à utiliser et fonctionnent avec les plateformes et technologies modernes.

Les plateformes .NET ont évolué depuis que nous avons introduit des outils pour les migrations, la génération de modèles automatique de base de données, etc. dans EF Core 1.0. Dans EF7, nous prévoyons de mettre à jour l’architecture des outils pour mieux prendre en charge les nouvelles plateformes, telles que .NET MAUI, et simplifier le processus dans des domaines tels que l’utilisation de plusieurs projets. Cela suppose de meilleurs commentaires en cas de problème, une meilleure intégration à la journalisation, de meilleures performances et un nouveau sucre.

EF Core et interfaces utilisateur graphiques

Suivi : Problème n° 26799 : améliorer l’expérience pour la liaison de données et les interfaces graphiques

Proposition de valeur : il est facile de créer des applications graphiques liées aux données avec EF Core.

EF Core est conçu pour bien fonctionner avec les scénarios de liaison de données, tels que ceux dans Windows Forms et .NET MAUI. Toutefois, il n’est pas toujours facile de faire le lien entre ces technologies. Pour EF7, nous prévoyons d’améliorer l’expérience de travail dans EF Core et dans Visual Studio pour faciliter la création d’applications liées aux données avec EF Core.

SqlServer.Core (Woodstar)

Suivi : Dépôt .NET Data Lab

Proposition de valeur : accès rapide et entièrement managé à SQL Server et Azure SQL pour les applications .NET modernes.

Microsoft.Data.SqlClient est un fournisseur de base de données ADO.NET complet pour SQL Server. Il prend en charge un large éventail de fonctionnalités SQL Server sur .NET Core et .NET Framework. Toutefois, il repose sur un ancien codebase volumineux avec de nombreuses interactions complexes entre ses comportements. Il est donc difficile d’étudier les gains potentiels qui pourraient être réalisés à l’aide des fonctionnalités .NET Core plus récentes.

L’année dernière, nous avons lancé un projet appelé « Woodstar » afin d’étudier le potentiel d’un pilote SQL Server hautement performant pour .NET. Nous prévoyons d’investir davantage dans ce projet dans le cadre d’EF7.

Important

L’investissement dans Microsoft.Data.SqlClient ne change pas. Ce fournisseur reste la méthode recommandée pour se connecter à SQL Server et Azure SQL, avec et sans EF Core. Il continuera à prendre en charge les nouvelles fonctionnalités de SQL Server à mesure qu’elles seront introduites.

Fournisseur Azure Cosmos DB

Suivi : problèmes avec l’étiquette « area-cosmos » et dans le jalon 7.0

Proposition de valeur : continuer à faire d’EF Core le moyen le plus simple et le plus productif de travailler avec Azure Cosmos DB.

Nous avons apporté des améliorations significatives au fournisseur de base de données Azure Cosmos DB pour EF Core dans la version 6.0. Ces améliorations ont créé une expérience de premier ordre pour travailler avec Azure Cosmos DB à partir d’EF Core, ce qui s’est traduit par une hausse significative de l’adoption. Nous prévoyons de poursuivre cette dynamique dans EF7 en apportant les améliorations supplémentaires suivantes au fournisseur Azure Cosmos DB :

Veillez à voter (👍) pour les fonctionnalités du fournisseur Azure Cosmos DB dont vous avez besoin afin que nous puissions déterminer où investir de la manière la plus avantageuse.

Expérience de migration

Suivi : Problème n° 22946 : améliorations des migrations de bases de données

Proposition de valeur : démarrer facilement des migrations et les utiliser ensuite efficacement dans des pipelines CI/CD.

Dans EF Core 6.0, nous avons introduit des bundles de migration qui ont permis d’améliorer considérablement l’expérience de déploiement de bases de données et d’applications natives cloud dans des systèmes d’intégration et de déploiement continus. Dans EF7, nous prévoyons d’apporter des améliorations supplémentaires dans ce domaine en fonction des commentaires des clients. Par exemple, nous prévoyons de prendre en charge l’exécution de toutes les migrations dans une seule transaction pour faciliter la récupération en cas de problème.

De plus, nous prévoyons d’améliorer l’expérience des développeurs qui se lancent dans les migrations. Nous souhaitons notamment leur permettre de créer automatiquement la base de données lors de l’apprentissage ou du démarrage d’un projet, puis de passer facilement à des migrations managées à mesure que le projet arrive à maturité. Sinon, pour les projets disposant d’une base de données existante, nous prévoyons de faciliter la création d’un modèle EF initial, puis de passer à la gestion de la base de données à l’aide de migrations à l’avenir.

.NET moderne

À mesure que .NET continue d’évoluer, nous voulons nous assurer que l’accès aux données reste une excellente expérience. Pour faciliter cela, nous prévoyons d’apporter des améliorations dans trois domaines dans le cadre d’EF7.

Trimming

Suivi : Problème n° 21894 : améliorer la prise en charge du découpage pour les applications EF Core afin de réduire la taille des applications

Proposition de valeur : applications plus petites pouvant être compilées efficacement par AOT.

EF Core effectue de nombreuses opérations de génération de code d’exécution. Cela constitue un défi pour les modèles d’application qui dépendent de la suppression du code inutilisé (« tree shaking ») de l’éditeur de liens, tels que Xamarin et Blazor, et les plateformes qui n’autorisent pas la compilation dynamique comme iOS. Nous prévoyons d’améliorer considérablement le découpage du code inutilisé dans EF7. Cela permettra de réduire la taille des assemblys lors de l’utilisation d’EF Core, ce qui aura pour effet de faciliter le déploiement et de rendre la compilation anticipée (AOT) plus efficace.

Faire évoluer System.Linq.Expression

Proposition de valeur : utiliser les fonctionnalités modernes du langage C# dans les requêtes LINQ.

Nous travaillons avec l’équipe Roslyn sur un plan permettant d’utiliser davantage de fonctionnalités C# dans les expressions LINQ. Il s’agit d’un travail continu qui sera principalement suivi en dehors du dépôt EF Core.

Traduire de nouveaux opérateurs LINQ

Suivi : Problème n° 25570 : prendre en charge les nouvelles fonctionnalités de .NET LINQ

Proposition de valeur : utiliser les nouveaux opérateurs LINQ lors de la traduction des requêtes LINQ en SQL.

De nouveaux opérateurs LINQ ont récemment été ajoutés à la bibliothèque de classes de base et d’autres devraient être ajoutés à l’avenir. Le problème n° 25570 suit l’ajout de la prise en charge de ces éléments au fournisseur LINQ EF7. Ce problème sera mis à jour à mesure que de nouveaux opérateurs LINQ sont ajoutés. Comme pour tous les opérateurs LINQ existants, nous n’ajouterons la prise en charge que lorsque l’opérateur disposera d’une traduction raisonnable et utile vers la base de données.

Ouvrir la télémétrie pour les fournisseurs ADO.NET

Suivi : Problème n° 22336 : normaliser sur DiagnosticSource/OpenTelemetry pour le suivi de base de données

Proposition de valeur : télémétrie multiplateforme conforme aux normes de l’industrie qui peut être surveillée dans l’outil de votre choix.

OpenTelemetry est une initiative de la Cloud Native Foundation visant à promouvoir un mécanisme de télémétrie commun pour les logiciels natifs cloud. Concernant les bases de données, cela inclut l’établissement d’une norme de télémétrie pour le client de base de données. Dans le cadre d’EF7, nous prévoyons d’accomplir le travail nécessaire pour faire bénéficier aux fournisseurs ADO.NET dans l’écosystème .NET de la télémétrie ouverte. Nous devrons notamment travailler avec la communauté sur les fournisseurs open source MySQL et Npgsql, ainsi que sur Microsoft.Data.Sqlite. Nous contacterons également d’autres fournisseurs, et nous encouragerons les fournisseurs ADO.NET à nous contacter s’ils sont intéressés.

Améliorations apportées à System.Data

Suivi : problèmes dans le dépôt dotnet\runtime avec l’étiquette area-System.Data dans le jalon 7.0

Proposition de valeur : meilleur accès aux données de bas niveau au profit de l’ensemble du code de niveau supérieur.

Comme pour chaque version, nous avons l’intention d’explorer les améliorations apportées à l’API d’accès aux bases de données de bas niveau de .NET, System.Data. Nous nous concentrerons sur l’amélioration des performances (notamment la réduction des allocations de mémoire en éliminant le boxing lors de l’utilisation de l’API) et de la convivialité.

L’étendue des améliorations précises sera déterminée ultérieurement en fonction de la faisabilité.

Étudier l’accès aux données pour le cloud natif

Proposition de valeur : faire évoluer l’accès aux données .NET pour prendre en charge les approches modernes telles que les microservices et le cloud natif.

Dans le cadre d’EF7, nous prévoyons de rechercher des approches modernes d’accès aux données sur les plateformes .NET, en particulier en référence aux microservices et aux applications natives cloud. Cette recherche contribuera à stimuler les investissements futurs dans les technologies d’accès aux données pour .NET.

Thème : voie claire à suivre à partir d’EF6

Suivi : Problème n° 1180 : fournir un guide plus complet sur le déplacement à partir d’EF6

Proposition de valeur : déplacer facilement votre application d’EF6 vers EF7.

EF Core a toujours pris en charge de nombreux scénarios non couverts par la pile EF6 héritée en offrant généralement des performances bien supérieures. Toutefois, EF6 prend également en charge des scénarios non couverts par EF Core. EF7 prendra en charge bon nombre de ces scénarios, ce qui permettra de déplacer davantage d’applications d’EF6 (version héritée) à EF7. En même temps, nous prévoyons de développer un guide complet de déplacement pour les applications passant d’EF6 (version héritée) à EF Core.

Une grande partie des tâches dans ce thème recoupe celles déjà décrites ci-dessus. Voici quelques-unes des tâches les plus importantes :

De plus, nous prévoyons d’indiquer clairement sur le dépôt GitHub EF6 hérité que nous ne prévoyons pas de travailler sur EF6 à l’avenir. La seule exception est la prise en charge d’EF6 avec Microsoft.Data.SqlClient. Toutefois, seul le runtime sera pris en charge. L’utilisation du concepteur EF6 dans Visual Studio nécessitera toujours System.Data.SqlClient.

Notez qu’EF Core dispose d’une architecture fondamentalement différente de celle d’EF6. En particulier, il n’utilise pas de spécification EDM (Entity Data Model). Cela signifie que certaines fonctionnalités telles que EDMX et EntitySQL ne seront jamais prises en charge dans EF Core.

Thème : performances

Un niveau élevé de performances est un principe fondamental d’EF Core, de l’accès aux données de niveau inférieur et de .NET dans son ensemble. Chaque version fait l’objet d’un travail important sur l’amélioration des performances. Comme toujours, ce thème implique de nombreuses investigations itératives, qui détermineront ensuite où nous concentrerons nos ressources.

Performances des insertions et mises à jour de base de données

Suivi : Problème n° 26797 : améliorer le suivi des modifications et mettre à jour les performances

Proposition de valeur : insertions et mises à jour de bases de données hautes performances à partir d’EF Core.

Au cours des dernières versions, nous nous sommes concentrés sur l’amélioration des performances d’EF Core au niveau des requêtes sans suivi. Pour EF7, nous prévoyons de nous concentrer sur les performances liées aux insertions et aux mises à jour de bases de données. Il s’agit notamment des performances des requêtes de suivi des modifications, des performances de DetectChangeset des performances des commandes d’insertion et de mise à jour envoyées à la base de données.

Une partie de ce travail inclut l’implémentation de mises à jour en bloc (basées sur des ensembles), considérées ci-dessus comme une fonctionnalité très demandée. Toutefois, nous prévoyons également d’améliorer les performances des mises à jour traditionnelles avec SaveChanges.

Score composite TechEmpower

Suivi : Problème n° 26796 : améliorer les performances dans le score composite TechEmpower

Proposition de valeur : mises à jour des données de bas niveau hautes performances pour toutes les applications .NET.

Nous exécutons depuis plusieurs années les benchmarks TechEmpower conformes aux normes de l’industrie pour mesurer les performances de .NET sur une base de données PostgreSQL. Dans les deux dernières versions, nous avons considérablement amélioré le benchmark Fortunes pour l’accès aux données de bas niveau et EF Core.

Dans le cadre d’EF7, nous prévoyons d’améliorer spécifiquement le score composite TechEmpower. Ce score mesure les performances dans un large éventail de scénarios.

Fonctionnalités diverses

Suivi : problèmes avec l’étiquette « type-enhancement » dans le jalon 7.0

Proposition de valeur : amélioration continue d’EF Core pour répondre aux exigences existantes et évolutives des applications.

Les diverses fonctionnalités prévues pour EF 7.0 incluent, mais sans s’y limiter :

Suggestions

Vos commentaires sur la planification sont importants. Veuillez ajouter vos commentaires ou suggestions d’ordre général concernant le plan au problème GitHub n° 26994. La meilleure façon d’indiquer l’importance d’un problème est de voter (👍) pour ce problème sur GitHub. Ces données seront ensuite intégrées au processus de planification de la prochaine version.