variable de session ou method static

Le
OlivierH
Bonjour à tous,

Je me pose la question des limites de variable de session,
j'ai besoin de memoriser tout le long de la session
l'ID, le NOM, niveau d'acces , nom de societe.
Et je me dit que cela doit alourdir l'application voir planter celle-ci.

Comment connaitre la limite du nomnbre de var de session par user.
ou
Sinon est ce que le mieux serait de charger une methode static
qui va lire dans SqlServer à chaque load de page afin de recuperer les
infos ?

D'avance Merci
Olivier,
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jérémy Jeanson
Le #19285731
Bonjour Olivier,

Ta question peux sembler légitime cependant Microsoft ne semblant pas
communiquer sur le nombre limite de valeurs pouvant être stockées dans
la session. On peut supposer qu'il est relativement élevé.

Pour ce qui est de l'idée de stocker tes variables sous SQL, c'est
effectivement une idée intéressante mais qui va te forcer à te poser un
grand nombre de question sur comment réagire pour chaque cas (fin
d'utilisation de l'applciation, entretien des tables SQL.. vidage des
celles-ci)...
Enfin beaucoup de choses peut être un peu lourdes quand on sait que le
Framework .net inclue nativement la possibilité d'effectuer la
persistance des sessions en base de données.

... de plus dans ton cas il semble s'agir d'information
d'authentification et de profil utilisateur... pourquoi ne pas utiliser
les mechanisme intégré au framework tel que le MembershipProvider,
RoleProvider... il permettent aussi la gestion d'information
personnalisées sur les utilisateurs.

Regardes bien de ce côté, il y a de forte chances que cela t'évites de
longues et pénibles heures de codage.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
OlivierH
Le #19290801
Bonjour Jérémy et merci pour ta reponse.

Aurais tu un exemple sur ces classes : MembershipProvider, RoleProvider

Est ce viable 5 variable de session pour 500 comptes utilisateurs
ouvert, et qui n'accedent pas
en silmutané sur l'appli tous les jours.

Olivier



Jérémy Jeanson a écrit :
Bonjour Olivier,

Ta question peux sembler légitime cependant Microsoft ne semblant pas
communiquer sur le nombre limite de valeurs pouvant être stockées dans
la session. On peut supposer qu'il est relativement élevé.

Pour ce qui est de l'idée de stocker tes variables sous SQL, c'est
effectivement une idée intéressante mais qui va te forcer à te poser
un grand nombre de question sur comment réagire pour chaque cas (fin
d'utilisation de l'applciation, entretien des tables SQL.. vidage des
celles-ci)...
Enfin beaucoup de choses peut être un peu lourdes quand on sait que le
Framework .net inclue nativement la possibilité d'effectuer la
persistance des sessions en base de données.

... de plus dans ton cas il semble s'agir d'information
d'authentification et de profil utilisateur... pourquoi ne pas
utiliser les mechanisme intégré au framework tel que le
MembershipProvider, RoleProvider... il permettent aussi la gestion
d'information personnalisées sur les utilisateurs.

Regardes bien de ce côté, il y a de forte chances que cela t'évites de
longues et pénibles heures de codage.


Jérémy Jeanson
Le #19308651
Bonjour Olivier,

Tel quel je n'ai pas d'exemeple tout fait sur l'usage des Providers
Membership et Role. Mais de tête je crois qu'il sont présentés par le
coach asp net que tu peux trouver via la MSDN.

J'ai moi même réalisé un article sur les bonnes pratiques de base
http://jjeanson.fr/1/Post.aspx?post~91e558-24f2-4bba-97b1-dfdc553cc278

Mais celui-ci sous entant tout de même de savoir à quoi servent les
providers, je te conseil donc dans un premier temps de faire un petit
tour de la MSDN.

Pour ce qui est de ton volume de session : c'est un peu le genre de
question où l'on tendance à vouloir répondre oui pourquoi pas... cela
semble correspondre à un cas à peu près courant.

Donc moi je te dirais oui car je ne crois pas qu'il faillent se poser
plus de question dans ton cas.

Après pour donner plus d'informations sur ce qui se fait (plutôt ce que
j'ai vu dans le douloureux monde réel)...

Si on veut construire une réponse complet te il faut garder à l'esprit
que cela ne représente pas la totalité des situations (nombre de
serveurs web, caractéristiques de ceux-ci... etc..). Mais je ne pense
pas que cela te concerne.
Et puis il y a le volume de donnée stockés... il ne faut pas rêver, la
session c'est sympathique pour garder temporairement des informations à
un instant T. Cela ne sert pas à faire de la persistance de données.

J'ai constaté dans la plupart des cas que pour une application qui
utilise des variables de session on en a souvent 1 ou 2, et rarement
plus. Par contre on arrive vite à en faire un peu plus quand on veux
faire une application d'e-commerce... et là la base de données peut être
plus avisées. Mais dans la réalité les développeurs on tendance à se
dire que ça ne sert pas à grand chose... en fait ils préfèrent la
session car c'est ce quil faisaient en PHP... mais là c'est une autre
histoire et malheureusement le monde de la théorie et de la pratique ne
font pas encore bon ménage.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
OlivierH
Le #19344401
Super Jeremy,

je suis resté à gerer mes classes de login et à bloquer les
authorisation à chaque
mais ton code simple et claire m'a permis de comprendre comment gerer.

UN grand merci
Olivier

Jérémy Jeanson a écrit :
Bonjour Olivier,

Tel quel je n'ai pas d'exemeple tout fait sur l'usage des Providers
Membership et Role. Mais de tête je crois qu'il sont présentés par le
coach asp net que tu peux trouver via la MSDN.

J'ai moi même réalisé un article sur les bonnes pratiques de base
http://jjeanson.fr/1/Post.aspx?post~91e558-24f2-4bba-97b1-dfdc553cc278

Mais celui-ci sous entant tout de même de savoir à quoi servent les
providers, je te conseil donc dans un premier temps de faire un petit
tour de la MSDN.

Pour ce qui est de ton volume de session : c'est un peu le genre de
question où l'on tendance à vouloir répondre oui pourquoi pas... cela
semble correspondre à un cas à peu près courant.

Donc moi je te dirais oui car je ne crois pas qu'il faillent se poser
plus de question dans ton cas.

Après pour donner plus d'informations sur ce qui se fait (plutôt ce
que j'ai vu dans le douloureux monde réel)...

Si on veut construire une réponse complet te il faut garder à l'esprit
que cela ne représente pas la totalité des situations (nombre de
serveurs web, caractéristiques de ceux-ci... etc..). Mais je ne pense
pas que cela te concerne.
Et puis il y a le volume de donnée stockés... il ne faut pas rêver, la
session c'est sympathique pour garder temporairement des informations
à un instant T. Cela ne sert pas à faire de la persistance de données.

J'ai constaté dans la plupart des cas que pour une application qui
utilise des variables de session on en a souvent 1 ou 2, et rarement
plus. Par contre on arrive vite à en faire un peu plus quand on veux
faire une application d'e-commerce... et là la base de données peut
être plus avisées. Mais dans la réalité les développeurs on tendance à
se dire que ça ne sert pas à grand chose... en fait ils préfèrent la
session car c'est ce quil faisaient en PHP... mais là c'est une autre
histoire et malheureusement le monde de la théorie et de la pratique
ne font pas encore bon ménage.


Jérémy Jeanson
Le #19357561
Heureux de savoir que ce code sert ;)
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Publicité
Poster une réponse
Anonyme