Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. ASP.NET avec C# sous Visual Studio 2022
  3. Gestion de l'état
Extrait - ASP.NET avec C# sous Visual Studio 2022 Conception et développement d'applications web
Extraits du livre
ASP.NET avec C# sous Visual Studio 2022 Conception et développement d'applications web Revenir à la page d'achat du livre

Gestion de l'état

Les différents moyens pour maintenir l’état

Le protocole HTTP étant déconnecté, le serveur web et l’application n’ont aucun moyen de se "souvenir" d’une requête formulée par un agent. Les différents procédés contournant cette difficulté sont appelés techniques de maintien de l’état.

1. Les champs cachés

Le langage HTML dispose de champs cachés. Ces champs sont caractérisés par leur nom et leur valeur, textuelle. Celle-ci est générée à la publication de la page et postée en retour du formulaire.

<html xmlns="http://www.w3.org/1999/xhtml" > 
<head runat="server"> 
    <title>Test de champ caché</title> 
</head> 
<body> 
<script runat="server"> 
    string valeur; 
</script> 
<% 
    if (Request["champ_cache"] != null && Request["champ_cache"] != "") 
        valeur = Request["champ_cache"]; 
    else 
    { 
        valeur = DateTime.Now.ToShortTimeString(); 
        Response.Write("Nouvel utilisateur connecté à " + valeur); 
    } 
%> 
    <form id="form1" runat="server">  
        <input type="hidden" name="champ_cache" value="<%= valeur %>" /> 
        <input type="submit" name="b" value="Recharger"...

Les sessions

Il est très fréquent de conserver pour chaque utilisateur des données de toute sorte : préférences de présentation, critères de tri, sélection d’articles... Les périodes pendant lesquelles ces données sont maintenues par l’application sont appelées sessions.

1. Utilisation de l’objet Session

Par rapport aux techniques précédentes de maintien de l’état, les sessions ne consomment que très peu de bande passante ; seul un jeton (matérialisé par un cookie ou une URI) est nécessaire pour identifier l’utilisateur. Les données sont en fait conservées par le serveur d’applications.

a. Mémorisation d’un objet et recherche

L’objet Session (également propriété de HttpContext.Current) s’utilise comme une table de hachage, les objets (ou valeurs) mémorisés sont identifiés par une clé qui sert d’index :

protected void cmd_redir_Click(object sender, EventArgs e) 
{ 
  Session["nom"] = txt_nom.Text; 
  Response.Redirect("session_page2.aspx"); 
} 

Pour retrouver la valeur mise en session généralement depuis une autre page, il convient d’utiliser la même clé et de procéder à un transtypage :

protected void Page_Load(object sender, EventArgs e) 
{ 
  string nom = Session["nom"] as string; 
  Label1.Text = nom; 
} 

Il est également nécessaire de vérifier que l’entrée correspondante à la clé existe, autrement, l’indexeur de Session renvoie null et le transtypage échoue :

// transtypage risqué si l'entrée idu n'existe pas 
int id_user = (int)Session["idu"];...

Les objets Application et Cache

1. L’objet Application

À la différence de l’objet Session, l’objet Application conserve des données accessibles à tous les utilisateurs d’un site web.

a. Utilisation

Comme l’objet Session, Application s’utilise comme un dictionnaire de termes identifiés par des clés.

protected void Page_Load(object sender, EventArgs e) 
{ 
  int c=0; 
  if (Application["compteur"] != null) 
    c = (int)Application["compteur"]; 
 
  c++; 
  Application["compteur"] = c; 
  Label1.Text = "Page visitée " + c + " fois"; 
} 

Les données sont conservées aussi longtemps que le processus de gestion de l’état le permet (aspnet_wp.exe, le service Windows de gestion de l’état ou SQL Server). Aucun cookie n’est nécessaire.

L’objet Application mémorise tout objet dont on lui communique la référence. Le programmeur doit cependant rester vigilant quant au maintien des champs statiques qui ne sont généralement pas sérialisés.

b. Verrouillage

Comme plusieurs pages, sollicitées par différents utilisateurs, peuvent accéder simultanément à l’objet Application, Microsoft a proposé un mécanisme de verrouillage.

Application.Lock(); 
Application["compteur"] = c; 
 
Application.UnLock(); 

Ce mécanisme doit pourtant être utilisé avec prudence ; le verrouillage concerne l’ensemble des données détenues par l’objet application. Comme s’il s’agissait d’une section critique, le verrou posé bloque les autres threads jusqu’à sa levée. Ceci entraîne...