- Composant Blazor QuickGrid
- Amélioration des performances de Blazor WebAssembly avec le jiterpreter
- Nouvel analyseur pour détecter les attributs FromBody multiples
- Nouvelles API dans ProblemDetails pour supporter des intégrations plus résilientes
- Nouvelle interface IResettable dans ObjectPool
- Amélioration des performances du transport par canaux nommés
Pour commencer
Pour commencer à utiliser ASP.NET Core dans .NET 8 Preview 2, installez le SDK .NET 8.
Si vous êtes sous Windows et que vous utilisez Visual Studio, nous vous recommandons d'installer la dernière version Visual Studio 2022 Preview. La prise en charge de Visual Studio for Mac pour les aperçus de .NET 8 n'est pas encore disponible.
Mettre à niveau un projet existant
Pour mettre à niveau une application ASP.NET Core existante de .NET 8 Preview 1 à .NET 8 Preview 2 :
- Mettez à jour le cadre cible de votre application vers net8.0.
- Mettez à jour toutes les références du paquet Microsoft.AspNetCore.* en 8.0.0-preview.2.*.
- Mettez à jour toutes les références des paquets Microsoft.Extensions.* vers 8.0.0-preview.2.*.
Composant Blazor QuickGrid
Le composant Blazor QuickGrid fait désormais partie de .NET 8 ! QuickGrid est un composant de grille haute performance pour l'affichage de données sous forme de tableaux. QuickGrid est conçu pour être un moyen simple et pratique d'afficher vos données, tout en offrant des fonctionnalités puissantes telles que le tri, le filtrage, la pagination et la virtualisation.
Pour commencer à utiliser QuickGrid :
1. Ajouter une référence au package Microsoft.AspNetCore.Components.QuickGrid.
Code : | Sélectionner tout |
dotnet add package Microsoft.AspNetCore.Components.QuickGrid --prerelease
2. Ajouter le code Razor suivant pour rendre une grille très simple.
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | <QuickGrid Items="@people"> <PropertyColumn Property="@(p => p.PersonId)" Title="ID" Sortable="true" /> <PropertyColumn Property="@(p => p.Name)" Title="Name" Sortable="true" /> <PropertyColumn Property="@(p => p.BirthDate)" Title="Birth date" Format="yyyy-MM-dd" Sortable="true" /> </QuickGrid> @code { record Person(int PersonId, string Name, DateOnly BirthDate); IQueryable<Person> people = new[] { new Person(10895, "Jean Martin", new DateOnly(1985, 3, 16)), new Person(10944, "António Langa", new DateOnly(1991, 12, 1)), new Person(11203, "Julie Smith", new DateOnly(1958, 10, 10)), new Person(11205, "Nur Sari", new DateOnly(1922, 4, 27)), new Person(11898, "Jose Hernandez", new DateOnly(2011, 5, 3)), new Person(12130, "Kenji Sato", new DateOnly(2004, 1, 9)), }.AsQueryable(); } |
QuickGrid a été introduit à l'origine en tant que package expérimental basé sur .NET 7. Dans le cadre de l'intégration de QuickGrid dans .NET 8, nous avons apporté quelques modifications et améliorations à l'API. Pour mettre à jour une application Blazor existante qui utilise QuickGrid vers la version .NET 8, vous devrez peut-être procéder aux ajustements suivants :
- Renommer l'attribut Value du composant Paginator en State.
- Renommer l'attribut IsDefaultSort sur les colonnes en InitialSortDirection et ajouter IsDefaultSortColumn=true pour indiquer que la colonne doit toujours être triée par défaut.
- Suppression de l'attribut ResizableColumns sur QuickGrid. La prise en charge intégrée des colonnes redimensionnables a été supprimée.
Amélioration des performances de Blazor WebAssembly avec le jiterpreter
Le jiterpreter est une nouvelle fonctionnalité d'exécution de .NET 8 qui permet une prise en charge partielle du JIT dans l'interpréteur IL de .NET afin d'améliorer les performances d'exécution.
Les applications Blazor WebAssembly peuvent exécuter du code .NET dans le navigateur grâce à un petit runtime .NET implémenté dans WebAssembly qui est téléchargé avec l'application. Ce runtime est un interpréteur .NET IL entièrement fonctionnel, raisonnablement petit en taille et permettant une itération rapide du développeur, mais il ne bénéficie pas des avantages en termes de performances d'exécution du code natif par le biais de la compilation juste à temps (JIT). La compilation juste à temps de WebAssembly nécessite la création de nouveaux modules WebAssembly à la volée et leur instanciation, ce qui pose des défis uniques au niveau de l'exécution. Les applications Blazor WebAssembly peuvent choisir de compiler à l'avance (AOT) en WebAssembly pour améliorer les performances d'exécution, mais au prix d'une taille de téléchargement beaucoup plus importante. Étant donné que certains modèles de codage .NET courants sont incompatibles avec l'AOT, l'interpréteur IL .NET est toujours nécessaire comme mécanisme de repli pour maintenir une fonctionnalité complète.
Le jiterpreter optimise l'exécution des bytecodes de l'interpréteur en les remplaçant par de minuscules blocs de code WebAssembly. En utilisant l'interpréteur comme base de référence, nous sommes en mesure d'optimiser les parties les plus importantes de l'application sans avoir à gérer des cas plus complexes ou plus obscurs et sans trop compliquer le runtime. Bien que le jiterpreter ne soit pas une implémentation JIT complète, il améliore de manière significative les performances d'exécution sans les surcharges de taille et de temps de construction de l'AOT. Le jiterpreter est également utile lors de l'utilisation de l'AOT en optimisant les cas où le runtime doit se rabattre sur l'interpréteur.
Dans .NET 8 Preview 2, le jiterpreter est automatiquement activé pour vos applications Blazor WebAssembly. Vous n'avez rien à faire pour l'activer.
Le jiterpreter peut accélérer de manière significative les performances des opérations de bas niveau. Par exemple, le test de micro benchmark suivant pour Span<byte>.Reverse() et String.Normalize() s'est déroulé respectivement 46,7 % et 86,9 % plus rapidement :
Ces améliorations s'additionnent et se traduisent par de meilleures performances pour les fonctionnalités des couches supérieures. Dans nos tests de sérialisation JSON, le jiterpreter est 40,8 % plus rapide :
Nous travaillons toujours à l'amélioration du jiterpreter avec des optimisations supplémentaires, de sorte que les performances du jiterpreter lors de la livraison de .NET 8 peuvent différer de ce que nous mesurons actuellement, mais jusqu'à présent, les résultats sont très prometteurs !
Nouvel analyseur pour détecter les attributs FromBody multiples
En plus des analyseurs ajoutés dans l'aperçu 1, nous introduisons un nouvel analyseur dans cette version qui fournit un avertissement utile si vous essayez de résoudre plus d'un paramètre à partir du corps dans une API minimale. Par exemple, le nouvel analyseur émettra un avertissement sur le code suivant.
Code : | Sélectionner tout |
1 2 | // ASP0024 app.MapPost("/todos", ([FromBody] Todo todo, [FromBody] User user) => ...); |
Pour résoudre l'avertissement de l'analyseur, limitez chaque gestionnaire à un seul paramètre résolu à partir du corps.
Code : | Sélectionner tout |
app.MapPost("/todos", ([FromBody] Todo todo, ClaimsPrincipal user) => ...);
Nouvelles API dans ProblemDetails pour prendre en charge des intégrations plus résistantes
Dans .NET 7, nous avons introduit le service ProblemDetailsService pour améliorer l'expérience de génération de réponses d'erreur conformes à la spécification ProblemDetails. Dans cette version, nous avons introduit une nouvelle API pour faciliter la mise en œuvre d'un comportement de repli si le ProblemDetailsService n'était pas en mesure de générer un ProblemDetail. La nouvelle API TryWriteAsync peut être utilisée comme suit dans l'intergiciel utilisateur :
Code : | Sélectionner tout |
1 2 3 4 5 6 | var problemDetailsService = httpContext.RequestServices.GetService<IProblemDetailsService>(); if (problemDetailsService == null || !await problemDetailsService.TryWriteAsync(new() { HttpContext = httpContext })) { // Your fallback behavior, since problem details was not able to be written. } |
Nouvelle interface IResettable dans ObjectPool
Microsoft.Extensions.ObjectPool*permet de regrouper des instances d'objets en mémoire. Les applications peuvent utiliser un pool d'objets si l'allocation ou l'initialisation des valeurs est coûteuse.
Dans l'aperçu 2, nous facilitons l'utilisation du pool d'objets en ajoutant l'interface IResettable. Les types réutilisables doivent souvent être ramenés à un état par défaut entre deux utilisations. Les types IResettable sont automatiquement réinitialisés lorsqu'ils sont renvoyés dans un pool d'objets.
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | public class ReusableBuffer : IResettable { public byte[] Data { get; } = new byte[1024 * 1024]; // 1 MB public bool TryReset() { Array.Clear(Data); return true; } } var bufferPool = ObjectPool.Create<ReusableBuffer>(); var buffer = bufferPool.Get(); try { await ProcessDataAsync(buffer.Data); } finally { bufferPool.Return(buffer); // Data is automatically reset } |
Amélioration des performances du transport par canaux nommés
Dans l'aperçu 1, nous avons annoncé la prise en charge de l'utilisation des canaux nommés avec Kestrel.
Dans l'aperçu 2, nous avons amélioré les performances de connexion des canaux nommés. Le transport de canaux nommés de Kestrel accepte désormais les connexions en parallèle et réutilise les instances de NamedPipeServerStream.
Temps de création de 100 000 connexions :
- Avant : 5,916 secondes
- Après : 2,374 secondes
Ces améliorations ont été suggérées par la communauté. Merci aux gens d'Unity d'avoir contribué à ce domaine !
Merci d'avoir essayé ASP.NET Core !
Daniel Roth, Principal Program Manager, ASP.NET
Source : Microsoft
Et vous ?
Que pensez-vous des améliorations apportées à ASP.NET Core dans ce second aperçu de .NET 8 ?
Voir aussi :
Microsoft publie .NET 8 Preview 1, le premier aperçu de la nouvelle version du framework, et ajoute plusieurs nouveautés dont l'extension de Native AOT à plus de scénarios et le support pour Linux
.NET 7 est maintenant disponible en tant que plateforme de développement unifiée de Microsoft, et apporte des améliorations pour .NET MAUI et le support de .NET pour ARM64
.NET : la version 7 du framework de développement d'applications serait la plus rapide de tous les temps, bien devant .NET 6 qui apportait jusqu'à 40 % de gain de vitesse par rapport à .NET 5