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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérémy Jeanson
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
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
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
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.
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.
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
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
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
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
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.
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.
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
Heureux de savoir que ce code sert ;) -- Jérémy JEANSON MCP http://www.jjeanson.fr
Heureux de savoir que ce code sert ;)
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
