Gestion de l'état

Conseil

Ce contenu est un extrait du livre électronique, Blazor for ASP NET Web Forms Developers for Azure (Blazor pour les développeurs ASP NET Web Forms pour Azure), disponible sur la documentation .NET 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 s’étendre à 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 épinglées 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 à résider 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 à plusieurs parties, vos utilisateurs s’attendent à ce que votre application mémorise les valeurs entre chaque requête. Écrivez les données entre chacune des publications de votre utilisateur dans un magasin de données afin qu’elles puissent être extraites et assemblées dans la structure de réponse de formulaire finale lorsque le formulaire à plusieurs parties est terminé.

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

Maintenir l’état avec session

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

La signature de l’objet .NET Framework Session n’est pas identique à l’objet ASP.NET Core Session. Envisagez la documentation relative à la nouvelle session ASP.NET Core 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 d’ASP.NET Core et l’état de session est disponible dans l’article Session et gestion de l’é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 toute l’application. L’état de l’application était un emplacement 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 Application était que les 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 requêtes et les utilisateurs, vous pouvez facilement les 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 est créé une seule fois sur le serveur, et la valeur VisitorCounter est extraite et sortie dans l’étiquette du composant. La valeur VisitorCounter doit être conservée et récupérée à partir d’un magasin de données de stockage pour la durabilité et la scalabilité.

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 – étendu à 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, puis le même localStorage est fourni par le navigateur
• sessionStorage – étendu à l’onglet actuel du navigateur de l’utilisateur. Si l’onglet est rechargé, l’état persiste. Toutefois, si l’utilisateur ouvre un autre onglet à votre application ou ferme et ouvre à nouveau 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 (Gestion d’état Blazor).

PrécédentSuivant