Planifier Entity Framework Core 5.0

Important

EF Core 5.0 a été mis en production. Cette page reste un enregistrement historique du plan.

Comme décrit dans le processus de planification, nous avons recueilli des commentaires des parties prenantes dans un plan provisoire pour la version EF Core 5.0.

Important

Ce plan est toujours un travail en cours. Rien ici n’est un engagement. Ce plan est un point de départ qui évoluera à mesure que nous en apprendrons davantage. Certaines choses qui ne sont pas prévues pour la version 5.0 peuvent être extraites. Certaines choses actuellement prévues pour la version 5.0 peuvent être annulées.

Informations générales

Numéro de version et date de publication

EF Core 5.0 est actuellement planifié pour la mise en production en même temps que .NET 5.0. La version « 5.0 » a été choisie pour s’aligner sur .NET 5.0.

Plateformes prises en charge

EF Core 5.0 est planifié pour s’exécuter sur toute plateforme .NET Standard 2.1, y compris .NET 5.0. Cela fait partie de la convergence de plateformes à l’échelle .NET plus générale vers .NET Core.

EF Core 5.0 ne s’exécutera pas sur .NET Framework.

Dernières modifications

EF Core 5.0 contiendra quelques changements cassants, mais ce sera beaucoup moins grave que ce qui était le cas pour EF Core 3.0. Notre objectif est de permettre la mise à jour sans interruption de la grande majorité des applications.

Il est prévu qu’il y ait des modifications avec rupture pour les fournisseurs de base de données, en particulier pour la prise en charge de TPT. Toutefois, nous pensons que le travail de mise à jour d’un fournisseur pour 5.0 sera inférieur à la nécessité de mettre à jour 3.0.

Thèmes

Nous avons extrait quelques principaux domaines ou thèmes qui constitueront la base des investissements importants en EF Core 5.0.

Mappage de plusieurs-à-plusieurs entièrement transparent par Convention

Développeurs principaux : @smitpatel, @AndriySvyrydet @lajones

Suivi par #10508

Taille de T-shirt : L

État : terminé

Plusieurs-à-plusieurs est la fonctionnalité la plus demandée (~506 votes) sur le backlog GitHub.

La prise en charge des relations plusieurs-à-plusieurs peut être divisée en trois domaines principaux :

• Ignorer les propriétés de navigation--Abordé par le thème suivant.
• Types d’entités conteneur de propriétés Ils permettent à un type CLR standard (par exemple, Dictionary) d’être utilisé pour les instances d’entité de telle sorte qu’un type CLR explicite n’est pas nécessaire pour chaque type d’entité. Suivi par #9914.
• Pratique pour une configuration facile des relations plusieurs-à-plusieurs.

En plus de la prise en charge de la navigation par omission, nous allons maintenant extraire ces autres zones de plusieurs-à-plusieurs dans EF Core 5.0 afin de fournir une expérience complète.

Propriétés de navigation plusieurs-à-plusieurs (autrement dit « ignorer les navigations »)

Développeurs principaux : @smitpatel et @AndriySvyryd

Suivi par #19003

Taille de T-shirt : L

État : terminé

Comme décrit dans le premier thème, la prise en charge de plusieurs-à-plusieurs a plusieurs aspects. Ce thème suit spécifiquement l’utilisation des navigations ignorées. Nous pensons que le bloqueur le plus significatif pour ceux qui souhaitent une prise en charge de type plusieurs-à-plusieurs ne peut pas utiliser les relations « naturelles », sans faire référence à la table de jointure, dans une logique métier telle que des requêtes. Le type d’entité de la table de jointure peut encore exister, mais il ne doit pas être dans la logique métier.

Mappage d’héritage table par type (TPT)

Développeur principal : @AndriySvyryd et @smitpatel

Suivi par #2266

Taille de T-shirt : XL

État : terminé

Nous faisons des TPT parce qu’il s’agit d’une fonctionnalité hautement demandée (environ 289 votes ; 3e au total) et qu’elle nécessite des modifications de bas niveau que nous pensons à la nature fondamentale du plan .NET 5 global. Nous pensons que cela entraînera des modifications avec rupture pour les fournisseurs de base de données, bien que ceux-ci soient nettement moins sévères que les modifications requises pour 3.0.

Inclure les entités filtrées

Développeur principal : @maumar

Suivi par #1833

Taille de T-shirt : M

État : terminé

Le modèle include filtré est une fonctionnalité très demandée (environ 376 votes : 2e au total) qui n’est pas une énorme quantité de travail, et que nous pensons autoriser à débloquer ou à faciliter de nombreux scénarios qui nécessitent actuellement des filtres au niveau du modèle ou des requêtes plus complexes.

Fractionner Include

Développeur principal : @smitpatel

Suivi par #20892

Taille de T-shirt : L

État : terminé

EF Core 3.0 a modifié le comportement par défaut pour créer une requête de SQL unique pour une requête LINQ donnée. Cela entraînait des régressions de performances importantes pour les requêtes qui utilisent Include pour plusieurs collections.

Dans EF Core 5.0, nous conservons le nouveau comportement par défaut. Toutefois, EF Core 5.0 permet désormais la génération de plusieurs requêtes pour la collection, notamment lorsque l’utilisation d’une seule requête entraîne des performances incorrectes.

Dépendants un-à-un requis

Développeurs principaux : @AndriySvyryd et @smitpatel

Suivi par #12100

Taille de T-shirt : M

État : terminé

Dans EF Core 3 0, tous les dépendants, y compris les types détenus, sont facultatifs (par exemple, Person.Address peut avoir la valeur null). Dans EF Core 5.0, les dépendants peuvent être configurés en fonction des besoins.

Rationaliser ToTable, ToQuery, ToView, FromSql, etc.

Développeurs principaux : @AndriySvyryd et @smitpatel

Suivi par #17270

Taille de T-shirt : L

État : terminé

Nous avons progressé dans les versions précédentes jusqu’à la prise en charge des SQL brutes, des types sans clé et des zones associées. Toutefois, il existe des lacunes et des incohérences dans la façon dont tout fonctionne dans son ensemble. L’objectif de 5.0 est de les corriger et de créer une bonne expérience pour la définition, la migration et l’utilisation de différents types d’entités et de leurs requêtes et artefacts de base de données associés. Cela peut également impliquer des mises à jour de l’API de requête compilée.

Notez que cet élément peut entraîner des modifications avec rupture au niveau de l’application, car certaines des fonctionnalités dont nous disposons actuellement sont trop permissive, ce qui permet à l’utilisateur de mener rapidement des gens sur des problèmes. Nous nous contenterons de bloquer certaines de ces fonctionnalités, ainsi que des conseils sur la marche à suivre.

Améliorations générales relatives aux requêtes

Développeurs principaux : @smitpatel et @maumar

Suivi : problèmes avec l’étiquette « area-query » dans le jalon 5.0

Taille de T-shirt : XL

État : terminé

Le code de traduction de la requête a été largement réécrit pour EF Core 3.0. Le code de requête est généralement dans un état bien plus robuste. Pour 5.0, nous ne prévoyons pas de modifier les requêtes majeures, en dehors de celles qui sont nécessaires pour prendre en charge les propriétés de navigation TPT et Skip. Toutefois, il y a toujours un travail important nécessaire pour résoudre une dette technique à partir de la révision 3.0. Nous prévoyons également de résoudre de nombreux bogues et d’implémenter de petites améliorations pour améliorer l’expérience globale des requêtes.

Migrations et expérience de déploiement

Développeur principal : @bricelam

Suivi par #19587

Taille de T-shirt : L

État : étendue/terminé

Étendue : la fonctionnalité des offres groupées de migrations a été différée jusqu’à la publication d’EF Core 5.0. Toutefois, plusieurs autres améliorations ciblées liées aux migrations seront incluses dans EF Core 5.0

Actuellement, de nombreux développeurs migrent leurs bases de données au moment du démarrage de l’application. C’est facile, mais cela n’est pas recommandé car :

• Plusieurs threads/processus/serveurs peuvent tenter de migrer la base de données simultanément
• Les applications peuvent tenter d’accéder à un état incohérent alors que cela se produit
• En général, les autorisations de base de données pour modifier le schéma ne doivent pas être accordées pour l’exécution de l’application
• Il est difficile de revenir à un état propre si un problème se pose

Nous souhaitons offrir une meilleure expérience ici, qui permet de migrer facilement la base de données au moment du déploiement. Cela doit :

• Fonctionner sur Linux, Mac et Windows
• Etre une bonne expérience sur la ligne de commande
• Prendre en charge les scénarios avec conteneurs
• Fonctionner avec des outils/flux de déploiement réels couramment utilisés
• Intégrer au moins Visual Studio

Le résultat est probablement de nombreuses améliorations de EF Core (par exemple, de meilleures migrations sur SQLite), ainsi que des conseils et des collaborations à long terme avec d’autres équipes pour améliorer les expériences de bout en bout qui vont au-delà d’EF.

Expérience des plateformes EF Core

Développeurs principaux : @roji et @bricelam

Suivi par #19588

Taille de T-shirt : L

État : étendue/terminé

Portée : des conseils et des exemples de plateforme sont publiés pour Blazor, Xamarin, WinForms et WPF. Xamarin et d’autres travaux de l’AOA/éditeur de liens sont maintenant prévus pour EF Core 6.0.

Nous avons de bonnes recommandations pour l’utilisation de EF Core dans des applications Web classiques basées sur MVC. Des conseils pour d’autres plateformes et modèles d’application sont manquants ou obsolètes. Pour EF Core 5.0, nous prévoyons d’examiner, d’améliorer et de documenter l’expérience d’utilisation de EF Core avec :

• Blazor
• Xamarin, y compris l’utilisation de l’article AOA/éditeur de liens
• WinForms/WPF/WinUI et éventuellement d’autres infrastructures U.I.

Il s’agit probablement de nombreuses améliorations de EF Core, ainsi que de conseils et de collaborations à long terme avec d’autres équipes pour améliorer les expériences de bout en bout qui vont au-delà d’EF.

Voici quelques-uns des éléments que nous prévoyons de consulter :

• Déploiement, y compris l’expérience d’utilisation des outils EF comme pour les migrations
• Modèles d’application, notamment Xamarin et Blazor, et probablement d’autres
• Expériences SQLite, y compris l’expérience spatiale et les reconstructions de tables
• Expériences en AOA et éditions de liens
• Intégration des diagnostics, y compris les compteurs de performances

Performances

Développeur principal : @roji

Suivi par problèmes avec l’étiquette avec « area-perf » dans le jalon 5.0

Taille de T-shirt : L

État : étendue/terminé

Portée : les améliorations de performances majeures dans le fournisseur Npgsql sont terminées. D’autres tâches de performances sont désormais prévues pour EF Core 6.0.

Par EF Core, nous prévoyons d’améliorer notre suite de tests de performances et d’améliorer les performances de l’exécution. En outre, nous prévoyons d’effectuer la nouvelle ADO.NET API de traitement par lot qui a été prototypée durant le cycle de version 3.0. En outre, au niveau de la couche ADO.NET, nous prévoyons des améliorations de performances supplémentaires pour le fournisseur Npgsql.

Dans le cadre de ce travail, nous prévoyons également d’ajouter ADO.NET compteurs de performance principaux/EF et d’autres diagnostics appropriés.

Documentation architecturale/contributeur

Documenteur de prospects : @ajcvickers

Suivi par #1920

Taille de T-shirt : L

État : coupé

L’idée ici est de faciliter la compréhension de ce qui se passe dans les éléments internes de EF Core. Cela peut être utile pour toute personne utilisant EF Core, mais la motivation principale est de faciliter la tâche aux utilisateurs externes pour :

• Contribuer au code EF Core
• Créer des fournisseurs de base de données
• Générer d’autres extensions

Mise à jour : malheureusement, ce plan était trop ambitieux. Nous pensons toujours qu’il s’agit d’un élément important, mais ça ne fonctionne malheureusement pas pour EF Core 5.0.

Documentation de Microsoft. Data. sqlite

Documenteur de prospects : @bricelam

Suivi par #1675

Taille de T-shirt : M

État : terminé. La nouvelle documentation est en direct sur Microsoft Learn.

L’équipe EF possède également le fournisseur de ADO.NET Microsoft. Data. Sqlite. Nous prévoyons de documenter entièrement ce fournisseur dans le cadre de la version 5.0.

Documentation générale

Documenteur de prospects : @ajcvickers

Suivi par problèmes dans le dépôt de documentation dans le jalon 5.0

Taille de T-shirt : L

État : en cours

Nous sommes déjà en train de mettre à jour la documentation pour les versions 3.0 et 3.1. Nous travaillons également sur :

• Révision des articles de prise en main pour les rendre plus accessibles/plus faciles à suivre
• Réorganisation des articles pour faciliter la recherche et l’ajout de références croisées
• Ajout de détails et de clarifications supplémentaires aux articles existants
• Mise à jour des exemples et ajout d’autres exemples

Correction des bogues

Suivi des problèmes étiquetés type-bug dans le jalon 5.0

Développeurs : @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Taille de T-shirt : L

État : en cours

Au moment de la rédaction, nous avons 135 bogues triés pour être corrigés dans la version 5.0 (avec 62 déjà corrigés), mais il existe un chevauchement significatif avec la section des améliorations de requête générales ci-dessus.

Le taux entrant (les problèmes qui se terminent par un travail dans une étape majeure) était d’environ 23 problèmes par mois au cours de la version 3.0. Ces derniers ne doivent pas nécessairement être corrigés dans 5.0. En guise d’estimation approximative, nous prévoyons de résoudre 150 problèmes supplémentaires dans le cadre de la version 5.0.

Petites améliorations

Suivi des problèmes étiquetés avec type-enhancement dans le jalon 5.0

Développeurs : @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Taille de T-shirt : L

État : terminé

En plus des fonctionnalités plus grandes décrites ci-dessus, nous avons également de nombreuses améliorations plus petites, planifiées pour la version 5.0, afin de corriger les « coupes papier ». Notez que la plupart de ces améliorations sont également couvertes par les thèmes plus généraux décrits ci-dessus.

En dessous de la ligne

Suivi des problèmes étiquetés avec consider-for-next-release

Il s’agit de correctifs de bogues et d’améliorations qui ne sont pas actuellement planifiés pour la version 5.0, mais nous examinerons la base des commentaires tout au long de la version, ainsi que des progrès réalisés sur le travail ci-dessus.

En outre, nous considérons toujours les questions les plus votées pendant la phase de planification. La réduction de ces problèmes d’une mise en production est toujours compliquée, mais nous avons besoin d’un plan réaliste pour les ressources dont nous disposons.

Suggestions

Vos commentaires sur la planification sont importants. La meilleure façon d’indiquer l’importance d’un problème est de voter (pouce vers le haut) pour ce problème sur GitHub. Ces données sont ensuite intégrées dans le processus de planification pour la prochaine version.