Gestion de l'état

Conseil / Astuce

Ce contenu est un extrait du livre électronique, Blazor pour les développeurs Web Forms ASP NET pour Azure, disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement qui peut être lu hors connexion.

Télécharger le PDF

La gestion de l’état est un concept clé d’applications Web Forms, facilitée par les fonctionnalités ViewState, État de session, État de l’application et Postback. Ces fonctionnalités avec état de l’infrastructure ont permis de masquer la gestion de l’état requise pour une application et de permettre aux développeurs d’applications de se concentrer sur les fonctionnalités à fournir. Avec ASP.NET Core et Blazor, certaines de ces fonctionnalités ont été déplacées et certaines ont été complètement supprimées. Ce chapitre explique comment maintenir l’état et fournir les mêmes fonctionnalités avec les nouvelles fonctionnalités de Blazor.

Gestion de l’état de requête avec ViewState

Lorsque vous discutez de la gestion de l’état dans l’application Web Forms, de nombreux développeurs pensent immédiatement à ViewState. Dans Web Forms, ViewState gère l’état du contenu entre les requêtes HTTP en envoyant un bloc de texte encodé volumineux vers le navigateur. Le champ ViewState peut être submergé par le contenu d’une page contenant de nombreux éléments, pouvant être étendu à plusieurs mégaoctets de taille.

Avec Blazor Server, l’application conserve une connexion continue avec le serveur. L’état de l’application, appelé circuit, est conservé dans la mémoire du serveur pendant que la connexion est considérée comme active. L’état est supprimé uniquement lorsque l’utilisateur quitte l’application ou une page particulière de l’application. Tous les membres des composants actifs sont disponibles entre les interactions avec le serveur.

Cette fonctionnalité présente plusieurs avantages :

• L’état du composant est facilement disponible et n’est pas reconstruit entre les interactions.
• L’état n’est pas transmis au navigateur.

Toutefois, il existe certains inconvénients pour la persistance de l’état des composants en mémoire à prendre en compte :

• Si le serveur redémarre entre la requête, l’état est perdu.
• Votre solution d’équilibrage de charge de serveur web d’application doit inclure des sessions sticky pour vous assurer que toutes les requêtes du même navigateur retournent au même serveur. Si une demande est envoyée à un autre serveur, l’état est perdu.
• La persistance de l’état du composant sur le serveur peut entraîner une sollicitation de la mémoire sur le serveur web.

Pour les raisons précédentes, ne vous fiez pas uniquement à l’état du composant stocké en mémoire sur le serveur. Votre application doit également inclure un magasin de données de stockage pour les données entre les requêtes. Voici quelques exemples simples de cette stratégie :

• Dans une application de panier d’achat, conservez le contenu des nouveaux éléments ajoutés au panier dans un enregistrement de base de données. Si l’état sur le serveur est perdu, vous pouvez le rétablir à partir des enregistrements de base de données.
• Dans un formulaire web multipart, vos utilisateurs s’attendent à ce que votre application mémorise les valeurs entre chaque requête. Écrivez les données entre chaque publication de votre utilisateur dans un magasin de données afin qu’elles puissent être extraites et réunies dans la structure de réponse finale lorsque le formulaire multipart est terminé.

Pour plus d’informations sur la gestion de l’état dans les applications Blazor, consultez ASP.NET Gestion de l’état Core Blazor.

Maintenir l’état avec session

Les développeurs Web Forms peuvent conserver des informations sur l’utilisateur actif avec l’objet dictionnaire Microsoft.AspNetCore.Http.ISession. Il est assez facile d’ajouter un objet avec une clé de chaîne à l’objet Session, et cet objet sera disponible ultérieurement pendant les interactions de l’utilisateur avec l’application. Dans une tentative d’éliminer la gestion de l’interaction avec HTTP, l’objet Session a rendu facile la gestion de l’état.

La signature de l’objet .NET Framework Session n’est pas la même que l’objet ASP.NET Core Session . Tenez compte de la documentation relative à la nouvelle session principale ASP.NET avant de décider de migrer et d’utiliser la nouvelle fonctionnalité d’état de session.

La session est disponible dans ASP.NET Core et Blazor Server, mais il est déconseillé de l’utiliser en faveur du stockage des données dans un référentiel de données de manière appropriée. L’état de session n’est pas non plus fonctionnel si les visiteurs refusent l’utilisation des cookies HTTP dans votre application en raison de problèmes de confidentialité.

La configuration pour ASP.NET Core et l'état de la session est disponible dans l'article Gestion de session et d'état dans ASP.NET Core.

État de l’application

L’objet Application dans l’infrastructure Web Forms fournit un référentiel de requêtes croisées massif pour interagir avec la configuration et l’état de l’étendue de l’application. L’état de l’application était un endroit idéal pour stocker différentes propriétés de configuration d’application qui seraient référencées par toutes les requêtes, quel que soit l’utilisateur qui effectue la requête. Le problème avec l’objet était que les Application données n’étaient pas conservées sur plusieurs serveurs. L’état de l’objet d’application a été perdu entre les redémarrages.

Comme avec Session, il est recommandé que les données se déplacent vers un magasin de stockage persistant accessible par plusieurs instances de serveur. S’il existe des données volatiles auxquelles vous souhaitez accéder entre les demandes et les utilisateurs, vous pouvez facilement le stocker dans un service singleton qui peut être injecté dans des composants qui nécessitent ces informations ou interactions.

La construction d’un objet pour maintenir l’état de l’application et sa consommation peut ressembler à l’implémentation suivante :

public class MyApplicationState
{
    public int VisitorCounter { get; private set; } = 0;

    public void IncrementCounter() => VisitorCounter += 1;
}

app.AddSingleton<MyApplicationState>();

@inject MyApplicationState AppState

<label>Total Visitors: @AppState.VisitorCounter</label>

L’objet MyApplicationState n’est créé qu’une seule fois sur le serveur, et la valeur VisitorCounter est extraite et sortie dans l’étiquette du composant. La VisitorCounter valeur doit être conservée et récupérée à partir d’un système de stockage de données pour assurer la durabilité et l’extensibilité.

Dans le navigateur

Les données d’application peuvent également être stockées côté client sur l’appareil de l’utilisateur afin qu’elles soient disponibles ultérieurement. Il existe deux fonctionnalités de navigateur qui permettent la persistance des données dans différentes étendues du navigateur de l’utilisateur :

• localStorage - étendue à l’ensemble du navigateur de l’utilisateur. Si la page est rechargée, le navigateur est fermé et rouvert, ou un autre onglet est ouvert avec la même URL, alors le même localStorage est fourni par le navigateur.
• sessionStorage - étendue à l’onglet du navigateur actuel de l’utilisateur. Si l’onglet est rechargé, l’état persiste. Toutefois, si l’utilisateur ouvre un autre onglet sur son application ou ferme et rouvre le navigateur, l’état est perdu.

Vous pouvez écrire du code JavaScript personnalisé pour interagir avec ces fonctionnalités, ou il existe un certain nombre de packages NuGet que vous pouvez utiliser pour fournir cette fonctionnalité. Un de ces packages est Microsoft.AspNetCore.ProtectedBrowserStorage.

Pour obtenir des instructions sur l’utilisation de ce package pour interagir avec localStorage et sessionStorage, consultez l’article Blazor State Management .

PrécédentSuivant