Lutter avec l'utilisation acceptable de la variable Session dans ASP.NET

Question

J'ai essayé de se sevrer de tout couper dans une variable de session dans ASP.NET (je viens d'un fond de programmation Windows), et j'ai généralement complètement cessé de stocker explicitement quelque chose dans un Variable de session Quelqu'un peut-il donner des directives sur ce que vous considérez comme des utilisations acceptables de la variable de session?

Voici un exemple spécifique ... Je charge un objet métier à partir de la base de données et remplit et édite l'écran. L'utilisateur peut modifier les valeurs et enregistrer. À l'ancienne, je chargerais l'objet métier, chargerais mon formulaire et enregistrerais l'objet métier dans une variable de session. Si l'utilisateur clique sur Enregistrer, je récupère l'objet métier de la variable de session, remplace les valeurs modifiées, puis l'enregistre. La nouvelle façon de charger l'objet métier depuis la base de données et de charger mon formulaire. L'utilisateur modifierait les valeurs et cliquera sur sauvegarder. Je rechargerais mon objet métier de la base de données, remplacerais les valeurs éditées, puis l'enregistrerais. Je ne suis pas un expert en programmation web, mais je pense que la première est fausse à cause de la mauvaise stigmatisation des variables de session, et je pense que la seconde est fausse parce que ça me semble être une mauvaise façon de le faire.). Ne prenons aucune forme de mise en cache ici. Comment pourrais-je gérer cela?

Answer 1

Je ne suis pas du tout offensé en rechargeant l'objet métier de la base de données sur le post pour sauvegarder les modifications des utilisateurs.

Cet objet doit provenir de quelque part sur cette publication, et la surcharge limitée associée à un appel DB rapide, comme saisir un objet spécifique est probablement votre meilleur pari.

Vos options pour obtenir cet objet métier retour dans la mémoire sur le dos de poste:

• Recevez de la DB à nouveau. Inconvénients: Certains (petits) surcharges de base de données supplémentaires
• Enregistrez-le dans la session de l'utilisateur. Contre: Potentiellement encore frapper la base de données (si l'état de session est stocké là) ou utiliser beaucoup de mémoire (si l'état de session est stocké là) et peut stocker plusieurs copies si plusieurs utilisateurs peuvent accéder à cet objet et pire, cette session objet pourrait être parti avec les utilisateurs de soumettre soumettre si ASP.NET purgé pour une raison quelconque.
• À partir du cache. Inconvénients: Utilise de la mémoire supplémentaire et vous devrez toujours aller à la base de données si le cache n'existe pas, mais je mettrais beaucoup d'argent que toute application a beaucoup de goulots de bouteille plus grands pour utiliser le cache.
• Viewstate. Vous POUVEZ stocker l'objet dans Viewstate (qui l'envoie au client, puis le client le reporte). Les inconvénients: La pire solution, à mon avis. L'ajouter à Viewstate signifie qu'il passe par-dessus le fil en aval et en amont et que la taille de la page est énorme. La session n'est pas la meilleure, mais Viewstate est le diable.

Answer 2

Avez-vous beaucoup d'utilisateurs?

Le stockage de vos objets de gestion dans une session est peut-être correct si votre site est à faible volume.

Si vous utilisez SQL Server pour stocker votre session, vous chargez de toute façon votre objet métier depuis la base de données. En règle générale, j'ai tendance à utiliser Session pour stocker uniquement les informations applicables à la vie de la session des utilisateurs. Les objets métier spécifiques à un seul formulaire Web ne correspondent pas vraiment à cette catégorie. Pour les sites à fort volume, cette stratégie vous aidera probablement à mieux évoluer. Cela dépend de tous les facteurs concernés.

:)

Answer 3

Rechargement un objet à partir de la base de données avant la mise à jour est potentiellement très dangereux. Vous pouvez finir par manquer toutes les violations de concurrence possibles.

Par exemple, si ce flux se produit:

1. écran d'édition d'affichage pour le client 1 sur l'ordinateur 1
2. écran d'édition d'affichage pour le client 1 sur l'ordinateur 2
3. mise à jour de la poignée au client 1 de l'ordinateur 1
4. mise à jour de la poignée au client 1 de l'ordinateur 2

Il est possible que le (4) devrait échouer parce que d'une violation de concurrence, c'est-à-dire que la mise à jour est en train d'écraser les modifications que l'ordinateur 2 ne connaissait pas. Mais en rechargeant à partir de la base de données, vous ignorez ces problèmes et implémentez les dernières mises à jour. Donc, pour ce genre de situation, je pense que mettre l'entité d'origine dans la session (ou dans un champ caché sur le formulaire) est absolument la bonne chose à faire si vous vous souciez de la concurrence.

Sans parler beaucoup de gens n'aiment pas frapper la base de données à nouveau pour la lecture supplémentaire ...