Applications ASP.

NET
avec VB.NET
Grard Frantz

Groupe Eyrolles, 2003,

ISBN : 2-212-11280-7

C h a p i t r e

Gestion de l'tat, la
session, les cookies
DA N S

C E

CH AP I TRE

Mise en vidence du problme

Stockage des donnes sur le client

Stockage des donnes sur le serveur

Dans les chapitres prcdents, nous avons essentiellement considr les pages de faon individuelle. Chacune d'elle effectuait un travail spcifique, les seules relations entre une page et une
autre tant un appel avec un hyperlien.
Nous avons galement vu comment traiter les donnes d'une page dans des formulaires. Avec
ASP.NET, le code qui procde l'affichage initial de la page et celui qui traite les donnes saisies
par l'utilisateur se trouvent dans la mme page.

221

Chapitre 7 - Gestion de ltat, la session, les cookies

Nous n'avons cependant pas encore examin comment effectuer un traitement sur plusieurs
pages et particulirement comment retrouver dans le code associ une page les donnes d'une
autre page.
Comme cela a t indiqu dans les chapitres prcdents, le Web est par essence un systme
sans tat : l'utilisateur demande une page, celle-ci est renvoye par le serveur, puis tout est
oubli ! Lors de la prochaine demande de l'utilisateur, le serveur ne se rappellera de rien.
En d'autres termes, le serveur ne fait que rpondre des demandes ponctuelles de l'utilisateur,
une par une, sans aucune connexion entre elles.
Cette situation peut vous sembler dsespre, mais heureusement l'infrastructure .NET ajoute
tout un ensemble de traitements spcifiques sur cette mcanique relativement primitive, afin de
vous aider construire de vritables applications Web. Certains de ces mcanismes sont automatiques, d'autres doivent tre programms explicitement.
On peut distinguer plusieurs situations et systmes pour grer l'tat, c'est--dire faire passer la
valeur de donnes d'une page une autre. Les quatre premires techniques se servent du client
pour stocker les donnes :

Utiliser le ViewState, l'tat d'affichage des pages Web mis en uvre dans des sacs d'tat
(state bags).

Utiliser des champs cachs.

Passer les donnes par l'URL.

Placer les donnes dans des cookies sur le poste de l'utilisateur.

Les techniques suivantes stockent les donnes sur le serveur :

Stocker les donnes dans des variables de session.

Faire de mme avec des variables d'application.

Utiliser le contexte.

Placer les donnes dans le cache.

La gestion de l'tat concerne deux catgories de donnes :

222

Les valeurs des variables de l'application, principalement les variables de la classe associe la page.

Les valeurs des proprits des contrles de la page.

Applications ASP.NET avec VB.NET

Mise en vidence du problme

Prenons un exemple simple pour montrer comment la gestion de l'tat diffre dans les applications Web de ce qu'elle est dans les applications classiques.
La page PageEtat1 prsente un contrle TextBox (txtNom) et un bouton OK (btnOK). Quand l'utilisateur clique sur le bouton, le contenu de la zone de saisie est recopi dans une variable de
classe appele Nom (il s'agit d'un membre de la classe associe la page) :
' Variable contenant le nom
Private Nom As String
Private Sub btnOK_Click(...) Handles btnOK.Click
' Stocke le nom dans une variable
Nom = txtNom.Text
End Sub

Un second bouton sur la page (btnAfficheNom) permet d'afficher dans un contrle Label
(lblNom) le contenu de la variable Nom (figure 7-1) :

Figure 7.1

La page PageEtat1 ne conserve pas la valeur de la donne

Private Sub btnAfficheNom_Click(...) Handles btnAfficheNom.Click

' Affiche le contenu de la variable
lblNom.Text = Nom
End Sub

223

Chapitre 7 - Gestion de ltat, la session, les cookies

Note
L'exemple se trouve dans la page EtatPage1 du projet Etat du rpertoire 07 des exemples.

Le seul problme avec ce code est qu'il ne fonctionne pas comme on le souhaite : le texte n'est
jamais affich dans le label ! Si on excute l'application pas pas, on peut voir que la variable
Nom est vide lors de la dernire affectation.
Cela s'explique par le fait qu' chaque demande d'une page de l'utilisateur, ASP.NET recre un
nouvel objet pour la gestion de la page, selon la classe qui lui est associe (dans notre exemple,
la classe est appele EtatPage1). Cet objet ne dure donc que le temps de traitement de la page
par le serveur, grosso modo entre les vnements Load et Unload de la page. Ds que la page
est retourne l'utilisateur, l'objet correspondant est dtruit et des donnes disparaissent
(figure 7-2).

Figure 7.2

224

chaque nouvelle page correspond un nouvel objet

Applications ASP.NET avec VB.NET

La solution cet pineux problme est de stocker les donnes, non pas dans des variables de
classe, mais dans une zone o elles seront retrouves d'une page l'autre (figure 7-3). ASP.NET
propose plusieurs techniques pour cela, qui sont prsentes dans les sections suivantes.

Figure 7.3

Les donnes sont stockes dans une zone spcifique

Stockage des donnes sur le client

Les techniques exposes dans cette section stockent les donnes sur le client. Si cela permet
d'allger la charge du serveur, les donnes sont transportes avec chaque demande du client
vers le serveur, et chaque rponse du serveur.

225

Chapitre 7 - Gestion de ltat, la session, les cookies

Les donnes d'tat de la page

chaque page est associ un tat d'affichage (View State), qui stocke l'ensemble des donnes
de la page et de ses contrles. Cet tat d'affichage est implment dans un objet de classe
StateBag (littralement, sac d'tat), qui enregistre les donnes sous la forme de paires de cls
et de valeurs, dans un dictionnaire.

Note
Pour que l'tat d'affichage soit oprationnel, il faut que la proprit EnableViewState de la page soit True.

Ces donnes sont transportes du serveur une page sur le poste de l'utilisateur, puis de celleci au serveur nouveau, dans un champ cach du formulaire (un champ de type <input
type=hidden>). Le contenu de ce champ correspond l'ensemble des valeurs qui se trouvent
dans l'objet StateBag, codes de telle faon qu'elles soient transportables sur le protocole HTTP
et qu'il ne soit pas facile de les dcoder ou de les modifier.
L'tat d'affichage n'est utilisable que sur la mme page appele plusieurs fois, pas entre plusieurs pages diffrentes.

Attention
Toutes les donnes stockes dans le StateBag sont transmises au client. Il convient donc d'en limiter la
taille. La mise en place de variables importantes dans le sac d'tat peut faire grossir les pages de faon
excessive.

On peut accder l'objet StateBag associ une page grce la proprit ViewState de l'objet
Page. La cl associe une donne est automatiquement cre si celle-ci n'existe pas, ou elle
est remplace dans le cas contraire. On peut ainsi crire :
ViewState("Nom") = Value

pour stocker le contenu de Value sous le nom Nom. On pourra ensuite relire cette donne :
Nom = ViewState("Nom")

On peut ainsi transformer la page de l'exemple prcdent afin de stocker le nom, non plus dans
une variable de la classe, mais dans l'objet StateBag de la page. Pour minimiser les modifica226

Applications ASP.NET avec VB.NET

tions, on peut remplacer la dclaration de la variable Nom par une proprit de mme nom et qui
utilise l'objet StateBag :
Private Property Nom() As String
Get
Nom = ViewState("Nom")
End Get
Set(ByVal Value As String)
ViewState("Nom") = Value
End Set
End Property

Ainsi, le code qui utilise la donne Nom reste le mme :

Private Sub btnOK_Click(...) Handles btnOK.Click
' Stocke le nom dans une variable
Nom = txtNom.Text
End Sub
Private Sub btnAfficheNom_Click(...) Handles btnAfficheNom.Click
' Affiche le contenu de la variable
lblNom.Text = Nom
End Sub

Avec cette nouvelle version, le nom s'affiche bien quand on clique sur le bouton (figure 7-4).

Figure 7.4

La page PageEtat1 conserve la valeur de la donne

227

Chapitre 7 - Gestion de ltat, la session, les cookies

Note
L'exemple se trouve dans la page EtatPage2 du projet Etat du rpertoire 07 des exemples.

Les proprits des contrles

Le sac de proprits rfrenc par la proprit ViewState de la page est utilis par ASP.NET pour
conserver les valeurs des proprits des contrles de la page. Il faut en fait distinguer deux
faons de dfinir la valeur d'une proprit :

En phase de cration, on peut donner des valeurs aux proprits des contrles l'aide de
l'environnement de conception des pages de la fentre des proprits, ou directement
dans le code HTML. Toutes ces modifications sont stockes dans la page aspx, dans le code
HTML, principalement sous la forme d'attributs de balises.

En phase d'excution, les valeurs des proprits peuvent tre modifies par des instructions de code Visual Basic .NET. Par exemple :
txtNom.BackColor = Color.Yellow

Les valeurs des proprits dfinies en phase de cration ne sont jamais perdues. Lors de la gnration d'une page, chaque contrle est cr avec les valeurs des proprits tablies initialement.
En revanche, les valeurs des proprits modifies par le code peuvent tre perdues, selon la
valeur de la proprit EnableViewState de la page et des contrles.
Nous allons illustrer cela travers une page comprenant deux contrles TextBox appels
txtNom1 et txtNom2. Un bouton dont le texte est En jaune change la couleur de fond des deux
contrles, en modifiant la valeur de leur proprit BackColor :
Private Sub btnChange_Click(...) Handles btnChange.Click
txtNom1.BackColor = Color.Yellow
txtNom2.BackColor = Color.Yellow
End Sub

Un second bouton, OK, ne fait rien de particulier, si ce n'est qu' son activation, la page est
soumise au serveur et regnre, sans qu'aucun code spcifique ne soit excut sur le serveur.
Initialement, la valeur de la proprit EnableViewState de la page et des contrles est True.
Quand on clique sur le bouton En jaune, la couleur de fond des deux contrles TextBox devient
bien jaune, car le code ci-dessus a modifi cette couleur. Quand on clique ensuite sur le bouton
OK, la couleur reste jaune bien qu'aucun code spcifique n'ait t excut sur le serveur. Cela
228

Applications ASP.NET avec VB.NET

signifie que la valeur de la couleur de fond des deux contrles a bien t place dans le sac de
proprits et a t utilise par ASP.NET lors de la rgnration des contrles aprs le clic sur le
bouton OK.
Si on donne la proprit EnableViewState du second contrle TextBox la valeur False, et qu'on
clique sur le bouton En jaune puis sur OK, le fond du premier contrle est bien jaune (EnableViewState est toujours True), mais celui du second contrle ne l'est plus (figure 7-5). L'tat du
contrle n'a pas t transmis.

Figure 7.5

L'tat n'est transmis que pour le contrle dont la proprit EnableViewState est True

Si maintenant on donne la proprit EnableViewState de la page la valeur False, la couleur

de fond des deux contrles texte est perdue aprs avoir cliqu sur OK, quelle que soit la valeur
de la proprit EnableViewState des contrles. Les valeurs des proprits des lments de la
page modifies par le code ne sont pas conserves d'une page l'autre.

Note
On peut voir les donnes qui sont transmises entre le client et le serveur par l'intermdiaire du sac d'tat,
en affichant le code source de la page dans le navigateur du client, et en recherchant la balise <input
type="hidden" name="__VIEWSTATE"/>. La valeur de cette balise correspond au contenu du sac d'tat cod.

Note
L'exemple se trouve dans la page Prop du projet Etat du rpertoire 07 des exemples.

229

Chapitre 7 - Gestion de ltat, la session, les cookies

Utilisation de champs cachs

Le sac d'tat prsent prcdemment stocke en fait les donnes dans un champ cach, sur le
client. On peut utiliser la mme technique pour stocker d'autres donnes. Il suffit, pour cela,
d'ajouter une balise de champ cach <input type="hidden"/> dans un formulaire. Lors de la
gnration de la page contenant le formulaire, on peut donner une valeur au champ cach, par
exemple un identificateur d'enregistrement. Quand l'utilisateur valide la page et renvoie le formulaire, l'application peut lire la valeur afin de retrouver l'identificateur en cours de traitement.
L'exemple suivant montre comment mettre cela en uvre dans un formulaire, en utilisant un
contrle serveur HTML. La page ChampCache comprend un bouton de commande et un champ
cach appel Cach (figure 7-6). Lors de l'initialisation de la page, dans le traitement de l'vnement Load pour la page, le champ cach est format avec une valeur correspondant, par
exemple, un identificateur :

Figure 7.6

La page ChampCache stocke une donne dans un champ cach

Private Sub Page_Load(...) Handles MyBase.Load

If Not IsPostBack Then
' Premier chargement, stocke l'identificateur
Cach.Value = 5
End If
End Sub

Quand on clique sur le bouton OK, le formulaire est soumis au serveur. On peut alors rcuprer
la valeur stocke dans le champ cach pour raliser les traitements ncessaires. Ici, la valeur
est affich dans un contrle Label :

230

Applications ASP.NET avec VB.NET

Private Sub btnVoir_Click(...) Handles btnVoir.Click

' Relit l'indentificateur
lblID.Text = Cach.Value
End Sub

Si vous affichez le code source de la page partir du navigateur, vous pouvez y voir la ligne
suivante. L'utilisateur lambda ignore ce champ, mais l'expert peut facilement le voir :
<input name="Cach" id="Cach" type="hidden" value="5" />

Note
L'exemple se trouve dans la page ChampCache du projet Etat du rpertoire 07 des exemples.

Passage de donnes par l'URL

Une autre technique de passage des donnes d'une page l'autre consiste les placer dans
l'URL, dans l'adresse de la page appeler.
Quand l'utilisateur clique sur un lien ou sur un bouton d'un formulaire, l'application ajoute des
paramtres l'URL correspondante. Le format d'une URL avec paramtres est le suivant :
URL?nom1=valeur1&nom2=valeur2

L'ensemble des paramtres est plac la fin de l'URL, aprs un point d'interrogation. Chaque
paramtre est constitu d'un nom et d'une valeur, spars par un signe =. Les paramtres sont
spars entre eux par un signe &.
Le nom et la valeur des paramtres placs dans l'URL sont soumis certaines restrictions. Il ne
peut notamment pas y avoir de caractres accentus ou d'espaces. On peut utiliser la mthode
UrlEncode de l'objet HttpServerUtility retourne par la proprit Server de la page. Cette
mthode prend en paramtre une chane de caractres et retourne la mme chane, dans laquelle
les caractres interdits ont t cods. La mthode UrlDecode effectue l'opration inverse.
La page appele par l'URL peut rcuprer ces donnes l'aide de la mthode QueryString de
l'objet HttpRequest retourne par la proprit Request de la page.
Les exemples de cette section et des suivantes mettent en uvre une page de saisie d'un nom,
SaisieNom. Cinq boutons permettent d'appeler une autre page avec une mthode de passage
du nom diffrente (figure 7-7).
231

Chapitre 7 - Gestion de ltat, la session, les cookies

Figure 7.7

La page de saisie d'un nom permet d'appeler d'autres pages et de leur passer des donnes

Quand on clique sur le premier bouton, Affiche avec URL, le code suivant est excut pour
construire l'URL avec ses paramtres :
Private Sub btnOKURL_Click(...) Handles btnOKURL.Click
Response.Redirect("AfficheNomURL.aspx?Nom=" & Server.UrlEncode(txtNom.Text))
End Sub

Ce code utilise la mthode UrlEncode. Le texte de la zone de saisie est ici Grard Frantz. Le
rsultat de l'appel de la mthode UrlEncode(txtNom.Text) est : G%c3%a9rard+Frantz. Le caractre accentu est cod, ainsi que l'espace.
La page appele, AfficheNomURL, rcupre le nom partir de l'URL grce la mthode QueryString, puis l'affiche dans la page (figure 7-8) :
Private Sub Page_Load(...) Handles MyBase.Load
lblNom.Text = Request.QueryString("Nom")
End Sub

232

Applications ASP.NET avec VB.NET

Figure 7.8

Affichage du nom aprs passage par l'URL

Note
L'exemple se trouve dans les pages SaisieNom et AfficheNomURL du projet Etat du rpertoire 07 des
exemples.

Stockage des donnes dans des cookies

Un cookie est du texte stock sur le poste du client. Il est gnralement enregistr la demande
du serveur, par l'intermdiaire de la proprit Cookies de l'objet HttpResponse retourn par la
proprit Response de la page. Il peut tre lu travers la proprit Cookies de l'objet HttpRequest retourn par la proprit Request de la page.

Note
Un cookie ne contient que du texte et il ne peut tre atteint que par l'application (le site Web) qui l'a crit.
Contrairement des croyances bien tablies, un cookie n'est donc pas dangereux, dans la mesure o il est
passif et ne correspond pas du code. Les sites Web utilisent souvent des cookies pour mmoriser le fait
que l'utilisateur est pass par une page, et pour ventuellement stocker des informations lies cet
utilisateur (par exemple ses gots, dduits de son parcours dans le site). Cela permet d'ajuster le contenu
des pages du site lors d'une visite ultrieure.

Pour crire un cookie, qui est un couple nom-valeur, il suffit de lui donner une valeur, en indiquant son nom comme paramtre de la collection Cookies. Si le cookie existait dj, il est
remplac, dans le cas contraire, il est cr :
sResponse.Cookies("MonCookie").Value = "La valeur"

233

Chapitre 7 - Gestion de ltat, la session, les cookies

Un cookie crit de cette faon n'est pas permanent : il n'existe qu'en mmoire, donc pendant la
dure de l'application. Il disparatra quand celle-ci s'arrtera.
Pour rendre un cookie permanent, il faut indiquer une date d'expiration. Par exemple :
Response.Cookies("MonCookie").Value = "La valeur"
Response.Cookies("MonCookie").Expires = #1/1/2030#

Le cookie sera alors crit sur le disque de l'utilisateur et y restera jusqu' la date d'expiration
ou jusqu' ce qu'il soit effac.

Note
L'emplacement prcis des cookies dpend du navigateur utilis. Sous Windows XP, par exemple, Internet
Explorer place les cookies dans des fichiers texte situs dans le rpertoire Cookies des donnes de
l'utilisateur.

On peut lire un cookie en utilisant la mme collection Cookies, mais applique l'objet HttpRequest. Voici le code qui relit le cookie crit prcdemment :
MonCookie = Request.Cookies("MonCookie").Value

Si le cookie existait dans cette application, sa valeur est retourne. Dans le cas contraire, la
valeur de retour est une chane de caractres vide.
L'ensemble des cookies d'une application est transmis avec chaque demande de l'utilisateur. Il
est donc prfrable de ne placer que de petites quantits de donnes dans les cookies, afin de
ne pas grossir la trame HTTP circulant sur le rseau, d'autant plus que la taille d'un cookie est
elle-mme limite.

Note
L'utilisation de cookies peut tre dsactive sur le poste de l'utilisateur. Si le fonctionnement de votre
application dpend de leur emploi, il faut soit disposer d'une mthode alternative, soit avertir l'utilisateur
que l'application ne fonctionnera pas correctement avec sa configuration.
L'application peut savoir si le navigateur autorise les cookies en interrogeant la proprit Cookies de l'objet
HttpBrowserCapabilities, retourn par la proprit Browser de Request : Request.Browser.Cookie est True
si le navigateur autorise les cookies, False dans le cas contraire.

234

Applications ASP.NET avec VB.NET

La page exemple SaisieNom (figure 7-7) dispose d'un bouton Affiche avec cookie. Quand l'utilisateur clique dessus, le contenu du champ de saisie est plac dans un cookie temporaire
appel Nom. L'application est ensuite redirige vers une autre page, l'aide de la mthode Redirect de l'objet HttpResponse :
Private Sub btnOKCookie_Click(...) Handles btnOKCookie.Click
Response.Cookies("Nom").Value = txtNom.Text
' Supprimez le commentaire de la ligne suivante pour rendre le cookie permanent
'Response.Cookies("Nom").Expires = #1/1/2030#
Response.Redirect("AfficheNomCookie.aspx")
End Sub

La page AfficheNomCookie affiche le texte lu dans le cookie (figure 7-9) :

Figure 7.9

Affichage du nom aprs passage par cookie

Private Sub Page_Load(...) Handles MyBase.Load

lblNom.Text = Request.Cookies("Nom").Value
End Sub

Note
L'exemple se trouve dans les pages SaisieNom et AfficheNomCookie du projet Etat du rpertoire 07 des
exemples.

235

Chapitre 7 - Gestion de ltat, la session, les cookies

Stockage des donnes sur le serveur

Toutes les techniques prsentes prcdemment stockent les donnes sur le poste du client.
Celles de cette section les placent sur le serveur. Cela prsente quelques avantages :

Les donnes ne sont jamais visibles par le client.

Elles ne circulent pas sur le rseau et ne l'encombrent donc pas.

Elles ne sont pas lies au poste utilis par le client, comme c'est le cas pour les cookies
(si l'utilisateur utilise un autre poste, il ne dispose pas de ses cookies).

Leur accs est plus rapide, puisqu'elles se trouvent dj sur le serveur.

Le stockage des donnes sur le serveur prsente galement quelques inconvnients :

Les donnes occupent de la place sur le serveur, ce qui peut devenir ennuyeux si beaucoup
d'utilisateurs accdent l'application.

L'utilisateur peut tre li au serveur sur lequel se trouvent les donnes, bien qu'ASP.NET
propose des solutions pour cela.

Les variables d'application

Une variable d'application est conserve dans un objet particulier, de classe HttpApplication,
retourn par la proprit Application de la page. Cet objet comprend des donnes lies une
application. Au fait, qu'est-ce qu'une application Web ? Il s'agit de l'ensemble des fichiers,
pages, gestionnaires, modules et code situs dans un rpertoire virtuel et ses sous-rpertoires
sur un serveur Web donn.
Pour crer une variable d'application, il suffit de la nommer et de lui donner une valeur, un peu
comme pour les cookies prsents plus haut :
Application("NomVariable") = "Valeur variable"

Si la variable du nom indiqu existait dj, sa valeur est remplace, sinon elle est cre.
L'utilisation de variables d'application est donc extrmement simple. Il faut cependant faire
quelques remarques :

236

Une variable d'application est vue par tous les utilisateurs de l'application. Il ne faut donc
pas y stocker des donnes spcifiques un utilisateur, mais plutt des donnes communes
toute l'application, par exemple le nom de la socit ou une table de taux de TVA.

Applications ASP.NET avec VB.NET

Les variables d'application sont stockes dans le serveur Web qui les cre. Dans le cas
d'une ferme de serveurs (plusieurs serveurs qui jouent des rles semblables), la demande
d'un utilisateur peut tre dirige vers un serveur ou un autre selon leur charge. Une application peut donc ne pas disposer des donnes cres par la mme application sur un autre
serveur.

Lors de la modification de la valeur d'une variable d'application, il existe un risque que

d'autres utilisateurs effectuent un changement de la mme variable au mme moment. Il
convient donc de synchroniser l'accs ces variables, comme cela est montr dans
l'exemple suivant.

On place donc gnralement dans les variables d'application des donnes en lecture seule. Ces
variables sont alors utilises comme une sorte de cache pour des donnes qui ne varient pas
ou peu pendant la dure de vie de l'application.
Il faut cependant bien initialiser les variables d'application quelque part. Cela peut tre fait
quand l'application dmarre, en plaant du code spcifique dans le fichier global.asax de
l'application qui est ajout un projet Web par Visual Studio .NET lors de sa cration. Ce fichier
comprend des donnes et du code globaux l'application. On peut notamment y ajouter des
procdures qui seront appeles par le serveur Internet quand certains vnements se produiront. Il suffit, pour cela, de driver une classe de la classe HttpApplication et d'y crire les
programmes ncessaires. Pour grer les variables application, on peut crire du code dans les
procdures suivantes :

Init et Application_OnStart sont appeles au dmarrage de l'application. On y insre

donc gnralement le code d'initialisation des variables.

Dispose et Application_OnEnd sont appeles quand l'application se termine.

Note
Une application dmarre la premire fois qu'un utilisateur appelle une page qui en fait partie. Si le serveur
Web est arrt, elle l'est aussi. D'autre part, si le fichier global.asax est modifi, l'application est arrte
puis redmarre.

On peut remarquer qu'il existe deux procdures pour le dmarrage et l'arrt de l'application.
Les constructeurs et destructeurs Init et Dispose sont appels pour chaque objet HttpApplication cr, tandis que les procdures Application_OnStart et Application_OnEnd sont
appeles la premire cration. Il est donc gnralement prfrable d'initialiser les donnes
dans le constructeur Init.

237

Chapitre 7 - Gestion de ltat, la session, les cookies

La page AfficheNomApplication affiche une donne place dans une variable Application
appele Nom par la page appelante, SaisieNom. Celle-ci excute le code suivant lors du clic sur
le bouton Affiche avec application :
Private Sub btnOKApplication_Click(...) Handles btnOKApplication.Click
Application.Lock()
Application("Nom") = txtNom.Text
Application.UnLock()
Response.Redirect("AfficheNomApplication.aspx")
End Sub

On peut remarquer dans ce code que l'affectation de la valeur la variable Application est
accompagne d'un appel aux mthodes Lock puis UnLock. Lock verrouille l'objet Application
afin d'viter qu'une modification y soit effectue en mme temps par un autre thread.

Attention
L'appel la mthode Lock verrouille l'objet Application de faon globale. Les autres pages qui
appelleraient cette mme mthode seraient bloques. Il convient donc de recourir UnLock aussi
rapidement que possible et de n'effectuer que des traitements courts entre les deux requtes.

La page AfficheNomApplication affiche la valeur stocke dans la variable Application lors de

son chargement :
Private Sub Page_Load(...) Handles MyBase.Load
' Donne initialie par la page appelante
lblNom.Text = Application("Nom")
' Donnes initialises dans Global.asax
lblInit.Text = Application("Init")
lblOnStart.Text = Application("OnStart")
End Sub

Vous pouvez remarquer que le code de traitement de l'vnement Load affiche galement les
valeurs de deux autres variables (figure 7-10). Celles-ci ont t initialises dans des procdures
vnement de Global.asax :
Public Class Global
Inherits System.Web.HttpApplication

238

Applications ASP.NET avec VB.NET

Figure 7.10

Affichage du nom aprs passage par une variable Application

Public Overrides Sub Init()

Application("Init") = "Donne initialise dans Init"
End Sub
Sub Application_OnStart(ByVal sender As Object, ByVal e As EventArgs)
Application("OnStart") = "Donne initialise dans Application_OnStart"
End Sub
End Class

Les variables partages

L'utilisation de l'objet Application pour conserver des donnes tait courante dans les versions
prcdentes d'ASP. Elle prsente cependant quelques inconvnients, particulirement le fait que
les donnes n'y sont pas types, ce qui allonge les temps de traitement lorsqu'on y accde.
On pourrait tre tent d'utiliser des variables d'instance de l'objet Application (appel Global
par dfaut) dclar dans Global.asax. Cela n'est cependant pas possible, car il peut exister plusieurs objets Application crs partir de la classe Global. Quand une page est appele sur le
serveur, ASP.NET peut, soit fabriquer un nouvel objet Global, soit utiliser un objet existant. On
ne peut donc pas avoir de certitude sur l'objet Global employ par une page, et ses variables
d'instance ne peuvent donc pas tre mmorises d'un appel l'autre.
Il est cependant possible de dclarer des variables partages dans la classe Global avec le motcl Shared. Une telle variable s'utilise indpendamment de la cration d'un objet, elle est donc
globale l'application.

239

Chapitre 7 - Gestion de ltat, la session, les cookies

Voici, par exemple, une variable dclare dans Global.ascx, dans la classe Global :
Public Class Global
Inherits System.Web.HttpApplication
Public Shared Nom As String

La variable Nom peut alors tre valorise dans une page, comme dans la page SaisieNom la
suite d'un clic sur le bouton Affiche avec variable Shared :
Private Sub btnOKShared_Click(...) Handles btnOKShared.Click
SyncLock Me
Global.Nom = txtNom.Text
End SyncLock
Response.Redirect("AfficheNomShared.aspx")
End Sub

Le problme de l'accs simultan la donne par plusieurs threads se pose nouveau. Il est
rgl ici en plaant le code qui accde la donne dans une section de synchronisation, ce qui
garantit qu'un seul thread peut excuter la section la fois.
L'utilisation de la donne se fait dans une autre page, AfficheNomShared (il n'est pas ncessaire
de synchroniser l'accs la donne en lecture seule, figure 7-11) :

Figure 7.11

240

Affichage du nom aprs passage par une variable partage

Applications ASP.NET avec VB.NET

Private Sub Page_Load(...) Handles MyBase.Load

lblNom.Text = Global.Nom
End Sub

Les variables de session

Si les variables d'application sont intressantes pour stocker les donnes d'une application,
elles ne permettent pas de distinguer un utilisateur d'un autre. Les variables de session rpondent cette insuffisance, car elles sont associes l'utilisateur courant.

La notion de session
Pour mettre en uvre les variables de session, ASP.NET dfinit une notion de session qui comprend l'ensemble des actions d'un utilisateur dans une application. Une session est reconnue
par un identificateur de session cr par ASP.NET. Il s'agit d'une chane de caractres de 120
bits (par exemple, 302dvbynpstxl3i0rugg1b45), dont l'unicit est garantie grce l'utilisation
d'un algorithme spcifique. De plus, la structure de cette chane est non triviale, ce qui vite
qu'elle soit manipule l'insu du systme (par exemple, pour se faire passer pour quelqu'un
d'autre).
Quand un nouvel utilisateur appelle une page d'une application ASP.NET pour la premire fois,
un nouvel identificateur lui est attribu. Celui-ci accompagne ensuite toutes les rponses du
systme et les demandes de l'usager, ce qui permet de l'identifier. Deux techniques peuvent
tre utilises pour cela : un cookie particulier enregistr sur le poste de l'utilisateur, ou l'inclusion de l'identificateur dans l'URL, essentiellement si les cookies ne sont pas autoriss par le
navigateur de l'utilisateur.
Pour accder aux informations d'une session, la classe Page expose une proprit, Session, qui
retourne une rfrence un objet HttpSessionState. Celui-ci dispose de proprits et de
mthodes, dont la proprit SessionID qui renvoie l'identificateur de session courant. On peut
crire, pour placer l'identificateur de session dans un contrle label appel lblSessionID :
lblSessionID.Text = Session.SessionID

Le rsultat est une chane de caractres comprenant l'identificateur de session (voir l'exemple
suivant).
La configuration de la faon dont la session fonctionne se fait dans le fichier Web.config, situ
dans le rpertoire d'une application Web. Il s'agit d'un fichier XML comprenant, entre autres,
une balise appele sessionState qui fait partie de la section system.web du fichier. Cette balise
comprend plusieurs attributs qui dfinissent les caractristiques de la session (tableau 7-1).

241

Chapitre 7 - Gestion de ltat, la session, les cookies

Tableau 7-1

Les attributs de la section system.web du fichier web.config.

Attribut

Signification

cookieless

Indique si des cookies sont utiliss pour transmettre l'identificateur de session

sur le poste du client (valeur False) ou l'URL (valeur True)

Mode

Dsigne l'emplacement des donnes de la session (notamment les variables).

Voir ci-dessous.

stateConnectionString

Il s'agit d'une chane qui identifie le serveur utilis si mode vaut StateServer.

sqlConnectionString

Chane qui identifie le serveur SQL utilis si mode vaut SQLServer.

Timeout

Dtermine le temps d'inactivit en minutes au-del duquel la session est

automatiquement termine.

Note
Le fichier Web.config est cr par Visual Studio lors de la cration d'une nouvelle application Web. Vous
pouvez double-cliquer dessus dans l'explorateur de solutions pour en afficher ou en modifier le contenu.

Voici le contenu initial de cette section, tel qu'il est gnr par Visual Studio :
<configuration>
<system.web>
...
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="20"
/>
...
</system.web>
</configuration>

Quand l'attribut cookieless a sa valeur par dfaut False, le SessionID est transmis sur le poste
de l'utilisateur par l'intermdiaire d'un cookie. En revanche, si on donne cookieless la valeur
True, le SessionID est transmis dans l'URL, sous la forme d'un pseudo-rpertoire dont le nom
est la valeur de l'identificateur.

242

Applications ASP.NET avec VB.NET

Attention
Si l'attribut cookieless a sa valeur par dfaut False et que les cookies ne sont pas oprationnels sur le
poste de l'utilisateur, l'identificateur de session et donc les valeurs des variables ne seront pas mmoriss.

L'attribut mode indique l'emplacement de stockage des variables. La modification de la valeur

de cet attribut peut avoir une influence sur les performances et sur la disponibilit des donnes
de session. Les valeurs possibles sont les suivantes :

Off, les donnes de session ne sont pas gardes. Les variables de session ne doivent donc
pas tre utilises si mode a cette valeur.

InProc, les donnes de session sont stockes en mmoire sur le serveur. Cette valeur
donne les meilleures performances (il s'agit d'ailleurs de la valeur par dfaut), mais ne
permet pas de conserver les donnes en cas de panne ou d'utilisation de plusieurs serveurs ou processus.

StateServer, les donnes de session sont gardes sur le serveur identifi par la valeur de
stateConnectionString. Cette chane doit comprendre l'adresse du serveur suivie du port
utiliser, qui est par dfaut 42424. La valeur par dfaut, tcpip=127.0.0.1:42424, indique
que les donnes sont stockes sur le serveur local (l'adresse IP 127.0.0.1 identifie le
serveur local).

SQLServer, les donnes de session sont stockes sur le serveur SQL Server identifi par
la valeur de sqlConnectionString. Il s'agit d'une chane de connexion SQL Server.

Les deux dernires options sont particulirement intressantes et n'existaient pas dans les versions prcdentes d'ASP. Elles permettent de partager les donnes de session entre plusieurs
processus.
La valeur StateServer indique que les donnes de la session sont places sur le serveur spcifi
par stateConnectionString (un serveur d'tat). On peut alors envisager deux configurations :

Il n'existe qu'un serveur Web, mais plusieurs processus peuvent faire fonctionner la mme
application. L'utilisation de cette valeur permet de ne pas lier un utilisateur un processus
particulier. La valeur InProc ferait que, si l'utilisateur tait connect un processus diffrent d'une page l'autre, les valeurs de ses variables de session seraient perdues.

Quand plusieurs serveurs Web sont utiliss pour la mme application (on parle de ferme
de serveurs), le serveur d'tat peut tre commun l'ensemble des serveurs Web. De cette
faon, les demandes d'un utilisateur ne sont pas lies un serveur physique particulier
et la rpartition de charge entre les serveurs peut tre pleinement exploite.

243

Chapitre 7 - Gestion de ltat, la session, les cookies

La valeur SQLState de l'attribut mode permet d'aller encore plus loin, puisque les donnes des
variables d'application sont places sur un serveur SQL Server. De cette faon, mme si un
serveur Web tombe en panne, les donnes ne sont pas perdues.
Le dernier attribut de la balise sessionState, timeout, indique le temps d'inactivit, en minutes,
aprs lequel la session est ferme. Par dfaut, cette valeur est de vingt minutes. La fermeture
d'une session permet de librer toutes les donnes qui lui sont associes. Si l'application gre
des donnes sensibles, comme un compte en banque, il peut tre prfrable de diminuer cette
valeur, afin de ne pas garder en mmoire des donnes concernant un utilisateur qui n'utilise
plus l'application. On peut d'ailleurs forcer une fin de session, en appelant la mthode Abandon :
Session.Abandon

Cela peut tre effectu, par exemple, en rponse un clic de l'utilisateur sur un bouton de dconnexion plac sur la page. Aprs la fermeture d'une session, automatiquement ou manuellement,
toutes ses donnes sont dtruites.

Les variables de session

Comme les variables d'application, les variables de session sont simplement fabriques en les
nommant : si la variable existe, elle est utilise, sinon elle est cre. Pour donner une valeur
la variable de session Nom, on peut simplement crire :
Session("Nom") = "Nouvelle valeur"

Note
Il n'est pas ncessaire de mettre en uvre un mcanisme de synchronisation pour les variables de session,
car elles ne sont normalement rejointes que par un seul thread, n'tant lies qu' un seul utilisateur.

L'initialisation des variables de session peut se faire dans une procdure Session_OnStart (ou
Session_Start) et Session_OnEnd permet d'effectuer les traitements de fin de session. Ces deux
procdures doivent tre crites dans le fichier global.asax, comme cela a t expliqu dans la
section relative aux variables d'application.
La page AfficheNomSession affiche une variable de session initialise lors de la saisie du nom
de l'utilisateur dans la page SaisieNom. Elle affiche galement la valeur d'une variable initialise
dans la procdure Session_OnStart (figure 7-12).

244

Applications ASP.NET avec VB.NET

Figure 7.12

Affichage de variables de session

La valorisation de la variable la suite de la saisie du nom est effectue par le code suivant :
Private Sub btnOKSession_Click(...) Handles btnOKSession.Click
Session("Nom") = txtNom.Text
Response.Redirect("AfficheNomSession.aspx")
End Sub

L'initialisation des variables dans global.asax est :

Sub Application_OnStart(ByVal sender As Object, ByVal e As EventArgs)
Application("OnStart") = "Donne initialise dans Application_OnStart"
End Sub
Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
Session("Start") = "Donne initialise dans Session_Start"
End Sub

Enfin, l'affichage des variables est ralis par le code suivant :

Private Sub Page_Load(...) Handles MyBase.Load
lblNom.Text = Session("Nom")
lblSessionID.Text = Session.SessionID
lblSession.Text = Session("Start")
lblSession1.Text = Session("OnStart")
End Sub

245

Chapitre 7 - Gestion de ltat, la session, les cookies

Le contexte
La proprit Context d'une page retourne l'objet HttpContext associ la page. Celui-ci fournit
des informations sur la requte HTTP ayant provoqu son appel. Parmi les membres de la classe
HttpContext, la proprit Handler donne accs un objet HttpHandler qui reprsente la page
l'origine de l'appel. Cela permet d'accder ses donnes.
Pour que le contexte permette de rcuprer les donnes de la page prcdente, il faut que
l'appel de la page se fasse l'aide de la mthode Server.Transfer et non pas
Response.Redirect.

Note
Les donnes du contexte ne sont valides que pour la requte en cours. Elles sont donc perdues lors de la
requte suivante.

L'utilisation du contexte peut se faire en castant la proprit Handler en un type correspondant la page appelante. La ligne suivante permet d'accder la proprit Nom dfinie dans la
page SaisieNom :
Private Sub Page_Load(...) Handles MyBase.Load
lblNom.Text = CType(context.Handler, SaisieNom).Nom
End Sub

Voici le code de la page SaisieNom (figure 7-13) :

' Proprit Nom pour le contexte
Public ReadOnly Property Nom() As String
Get
Return txtNom.Text
End Get
End Property
Private Sub btnOKContext_Click(...) Handles btnOKContext.Click
' Utilise Server.Transfer au lieu de Response.Redirect
Server.Transfer("AfficheNomContext.aspx")
End Sub

246

Applications ASP.NET avec VB.NET

Figure 7.13

Affichage d'une variable obtenue grce au contexte

Le cache
Le cache d'ASP.NET est un lieu de stockage de donnes qui peut tre utilis la fois pour cacher
des pages, c'est--dire les mmoriser afin d'viter de les rgnrer chaque demande, et pour
enregistrer des donnes. Pour le stockage de donnes, le cache ressemble donc l'objet Application dans la mesure o les valeurs qui y sont places sont prives l'application. Mais le
cache dispose galement de mcanismes complmentaires qui permettent de contrler la dure
de vie des donnes qu'il contient en librant la mmoire quand elle n'est pas utilise, ou de
conditionner les donnes des ressources externes.
Placer des donnes dans le cache se fait trs simplement, comme pour l'objet Application :
Private Sub btnOKCache_Click(...) Handles btnOKCache.Click
Cache("Nom") = txtNom.Text
Response.Redirect("AfficheNomCache.aspx")
End Sub

On peut galement utiliser les mthodes Insert et Add de l'objet Cache pour ajouter des donnes
dans le cache. Ces mthodes peuvent recevoir des paramtres complmentaires permettant de
dfinir, notamment, la dure de vie des donnes.
L'obtention des donnes du cache se fait tout aussi simplement (figure 7-14) :
Private Sub Page_Load(...) Handles MyBase.Load
lblNom.Text = Cache("Nom")
End Sub

247

Chapitre 7 - Gestion de ltat, la session, les cookies

Figure 7.14

Affichage de variables du cache

Note
Le cache dispose de fonctionnalits supplmentaires, comme la libration automatique des donnes quand
elles ne sont pas utilises

Rsum du chapitre

Dans ce chapitre, nous avons vu que si la gestion de l'tat est un vritable problme pour les
applications Web, elle dispose galement de nombreuses solutions. Plusieurs mcanismes permettent de stocker les donnes d'une page sur le client, ou sur le serveur. Des techniques
nouvelles dans ASP.NET permettent mme de stocker les donnes sur un serveur partag par
plusieurs serveurs Web.

248