Que mettre dans une variable de session

Question

Je suis récemment tombé sur une application Web ASP 1.1 qui mettait tout un tas de choses dans la variable de session, y compris tous les objets de données de base de données et même l'objet de connexion à la base de données. Il finit par être énorme. Lorsque la session Web arrive à expiration (quatre heures après que l'utilisateur a fini d'utiliser l'application), leurs transactions de base de données sont parfois annulées. Je suppose que cela est dû au fait que la connexion à la base de données n’est pas correctement fermée lorsque IIS tue la session.

Quoi qu'il en soit, ma question est: que devrait-il figurer dans la variable de session? Il est clair que certaines choses doivent être là. L'utilisateur sélectionne le plan qu'il souhaite modifier sur l'écran principal. L'identifiant du plan est donc intégré à la variable de session. Est-il préférable d'essayer de réduire la charge sur la base de données en stockant tous les détails concernant l'utilisateur (et son responsable, etc.) et le plan qu'ils modifient dans la variable de session ou devrais-je essayer de minimiser le contenu de la variable de session et interroger la base de données pour tout ce dont j'ai besoin dans l'événement Page_Load?

Answer 1

Il est assez difficile de répondre à cette question car elle est spécifique à une application, mais voici quelques conseils que j'utilise:

1. Mettez le moins possible dans la session.
2. Les sélections spécifiques à l'utilisateur qui ne doivent durer que pendant une visite donnée constituent un bon choix
3. souvent, les variables qui doivent être accessibles à plusieurs pages tout au long de la visite de l'utilisateur sur votre site (pour éviter de les transmettre de page en page) sont également utiles pour la mise en session.

D'après le peu que vous avez dit sur votre application, je sélectionnerais probablement vos données dans la base de données et essayerais de trouver des moyens de minimiser l'impact de ces requêtes au lieu de charger la session.

Answer 2

Ne ne pas mettre les informations de connexion à la base de données dans la session.

En ce qui concerne la mise en cache, j'éviterais si possible d'utiliser la session pour la mise en cache. Vous rencontrerez des problèmes dans lesquels une autre personne modifie les données qu'un utilisateur utilise. De plus, vous ne pouvez pas partager les données en cache entre utilisateurs. Utilisez le cache ASP.NET ou un autre utilitaire de mise en cache (comme Memcached ou Velocity).

En ce qui concerne ce que doit choisir dans la session, tout ce qui s'applique à toutes les fenêtres de navigateur qu'un utilisateur a ouvertes sur votre site (identifiant, paramètres de sécurité, etc.) devrait être dans la session. Des éléments tels que l'objet en cours de visualisation / d'édition doivent en réalité être des variables GET / POST échangées entre les écrans afin qu'un utilisateur puisse utiliser plusieurs fenêtres de navigateur pour travailler avec votre application (sauf si vous souhaitez empêcher cela).

Answer 3

NE PAS mettre des objets d'interface utilisateur en session.

Au-delà, je dirais que cela varie. trop de session peut vous ralentir si vous n'utilisez pas la session en cours car vous allez sérialiser beaucoup plus la vitesse du fournisseur. Cache et Session doivent être utilisés avec parcimonie et prudence. Ne mettez pas simplement en session parce que vous pouvez ou est pratique. Asseyez-vous et analysez si cela a du sens.

Answer 4

Idéalement, la session en ASP devrait stocker le moins de données possible. Stocker une référence à un objet tenant des ressources système ouvertes (en particulier une connexion à une base de données) est un tueur d'évolutivité certain. En outre, le stockage de données non validées dans une variable de session est une mauvaise idée dans la plupart des cas. Globalement, il semble que l'implémentation actuelle utilise abusivement des objets de session pour essayer de simuler une application avec état dans un environnement supposé sans état.

Bien qu'il soit très décrié, le modèle ASP.NET de gestion automatique de l'état via des champs cachés devrait éliminer la majorité du besoin de conserver quoi que ce soit dans les variables de session.

Ma règle générale est que plus l'application doit être évolutive (en termes d'utilisateurs / hits), moins vous pouvez vous en sortir en utilisant l'état de session. Il y a cependant un compromis. Pour les applications Web où l'utilisateur accède de manière répétée aux mêmes données et a généralement une session assez longue pour une utilisation du site, une mise en cache (si nécessaire dans des objets de session) peut réellement aider l'évolutivité en réduisant la charge sur le serveur de base de données. L'idée ici est qu'il est beaucoup moins cher et moins complexe de gérer la couche de présentation que la base de données principale. Bien sûr, avec toutes les choses, ce conseil devrait être pris avec modération et ne s'applique pas à toutes les situations, mais pour une application CRUD interne assez simple, il devrait vous être utile.

Answer 5

A une question très similaire a été posée à propos des sessions PHP plus tôt. Fondamentalement, les sessions sont un endroit idéal pour stocker des données spécifiques à l'utilisateur auxquelles vous devez accéder lors de plusieurs chargements de page. Les sessions NE sont PAS un bon endroit pour stocker des références de connexion de base de données vous feriez mieux d'utiliser un logiciel de regroupement de connexions ou d'ouvrir / fermer votre connexion à chaque chargement de page. En ce qui concerne la mise en cache des données dans la session, cela dépend de la manière dont les données de la session sont stockées, du niveau de sécurité dont vous avez besoin et de la spécificité des données pour l'utilisateur. Un meilleur pari serait d’utiliser quelque chose d’autre pour la mise en cache des données.

Answer 6

stocker des repères de navigation dans des sessions est délicat. Le même utilisateur peut avoir plusieurs fenêtres ouvertes, puis les modifications sont propagées de manière confuse. Les connexions à la base de données ne doivent définitivement pas être stockées. ASP.NET maintient le pool de connexions pour vous, pas besoin de recourir à votre propre sorcellerie. Si vous avez besoin de mettre en cache des éléments pendant de courtes périodes et que la taille du jeu de données est relativement petite, envisagez l'option ViewState (au prix d'un chargement plus volumineux sur la taille de la page)

Answer 7

A: Données relatives à un seul utilisateur uniquement. IE: un nom d'utilisateur, un identifiant. Sur most , un objet représentant un utilisateur. Des données relatives aux URL (comme où emmener quelqu'un) ou une pile de messages d'erreur sont parfois utiles pour accéder à la session.

Si vous souhaitez partager des contenus potentiellement entre différents utilisateurs, utilisez le magasin d'applications ou le cache. Ils sont de loin supérieurs.

Answer 8

Stephen,
Travaillez-vous pour une entreprise qui commence par "I", dont le site Web commence par "BC"? Cela ressemble exactement à ce que j’avais fait lorsque j’ai commencé à développer .net (jeune et stupide): j’ai fourré tout ce à quoi je pouvais penser en session et en application. Inutile de dire que c'était double plus ungood.
En général, évitez la séance autant que possible. Certes, les objets non sérialisables ne devraient pas y être stockés (connexions de base de données, etc.), mais même les gros objets sérialisables ne devraient pas l'être non plus. Vous ne voulez tout simplement pas les frais généraux.

Answer 9

Je garderais toujours très peu d’informations en session. Les sessions utilisent des ressources mémoire du serveur, ce qui est coûteux. Si vous enregistrez trop de valeurs en session, la charge sur le serveur augmente et les performances du site diminuent. Lorsque vous utilisez des serveurs d'équilibrage de charge, l'utilisation de la session peut rencontrer des problèmes. Donc, ce que je fais est d'utiliser un minimum de sessions ou aucune, utiliser des cookies si les informations ne sont pas très critiques, utiliser davantage les champs cachés et les sessions de base de données.