9
votes

Lorsque vous utilisez des sessions, c'est une mauvaise chose, et ce qui ne va pas avec ça?

Je sais que dans le serveur de communauté Ce qui signifie que vous ne pouvez pas utiliser des sessions, et quelques années, je me souviens que je travaillais sur un site web où nous étions non autorisé à utiliser des sessions.
À mon point de vue, les sessions sont un outil très utile si nous avons réussi à utiliser la bonne façon, mais utilise la variable de session dans un site Web est quelque chose de mauvais, quand c'est mauvais et quand ce n'est pas?

mise à jour
Et que pouvons-nous utiliser plutôt pour éviter son désordre?


0 commentaires

7 Réponses :


2
votes

Les sessions expirent, il est volatile afin qu'il puisse arriver que des sessions soient temps et telles que c'est moins


0 commentaires

0
votes

Vous ne voulez pas utiliser des sessions pour stocker des informations privées non plus. Sorte de la façon dont les gens essaient de stocker des mots de passe directement dans des cookies, ce qui est aussi un non-non.


0 commentaires

1
votes

Les gens ont toujours peur d'accepter des cookies, qui sont nécessaires pour utiliser des sessions. En outre, il y a des problèmes de sécurité.


3 commentaires

Les sessions de la biscotte existent (bien qu'ils aient leur propre ensemble de problèmes).


Oui, des sessions à la chaîne de requête par exemple. Je pourrais passer toute la nuit à discuter contre l'utilisation d'eux. :)


Vous pouvez discuter contre eux tout ce que vous voulez, cela ne les rendra pas moins existants.



8
votes

Les sessions ne sont pas mauvaises en soi . Mais ils ne devraient pas être abusés ni. Vous devez surtout éviter le "Oh, j'ai besoin de cette information ici et ici, stockons-la dans la session et la réutilise plus tard".

Au lieu de faire une conception OO appropriée où les informations sont transmises correctement dans les paramètres, la session est utilisée comme stockage global non organisé - ce qui conduit à un désordre potentiel.

Un tel état mondial empêche également la Testabilité. Une grande session non organisée conduit également à une utilisation accrue de la mémoire. Une alternative à l'état de la session peut être la ViewState, par exemple.

(Je ne sais pas si vous parlez de l'état de la session ou de tout le concept de session. Si c'est ce dernier, ma réponse n'est pas vraiment appropriée)


0 commentaires

2
votes

L'une des principales raisons pour lesquelles vous ne voudrez pas utiliser des sessions dans l'environnement de production est que la sessionID est transmise via des cookies (au moins dans JSP). Et, vous ne pouvez pas garantir que votre client aurait des cookies allumés tout le temps. Par conséquent, même si vous utilisez une session, il est recommandé de mettre en œuvre une nouvelle réécriture de l'URL. En conséquence, le conteneur utiliserait une session ainsi que la réécriture de l'URL pour la toute première demande (afin de déterminer si des cookies sont activés). Et, il utiliserait une session si le client accepte les cookies. Sinon, cela se tournerait vers la réécriture de l'URL.

Notez que lors de l'utilisation de la réécriture d'URL, vous devez vous assurer que la réponse a l'URL codée. De plus, si vous utilisez une session, vous devrez prendre en compte des événements étranges tels que le suivi de la session pour plus d'un navigateur sur le même système.


0 commentaires

0
votes

C'est une question intéressante et je conviens que les sessions peuvent être très désordonnées si elles ne sont pas utilisées correctement. Une approche pour l'atténuer est d'avoir un objet complexe entièrement complexe (comme le contenu du panier d'actionnement) stocké dans une session plutôt que d'avoir plusieurs sessions renversées dans la même application Web. Les sessions peuvent en réalité être stockées dans la base de données SQL Server en cas de panne de courant.


1 commentaires

"Stocké en une session plutôt que d'avoir plusieurs sessions renversées ..." Quoi?



2
votes

Parfois, l'état de la session juste existant tue la performance. Sérieusement, mettre une seule valeur booléenne dans les cas peut tuer votre performance dans certains cas. Voici un exemple spécifique:

Vous avez une page de tableau de bord et héberge plusieurs petits modules qui chargent chacun leur contenu via Ajax. Si vous utilisez la session, vous ne pouvez charger qu'un seul module à la fois car la session est verrouillée (par utilisateur) lors d'une demande. Si la session n'est pas utilisée, il n'y a pas de verrouillage et le navigateur sera en mesure de demander le nombre maximum de ressources (4 ou plus simultanément).

Voir "Demandes simultanées et état de la session" ici:

http://msdn.microsoft.com/en-us/library /ms178581.aspx

Si vous rencontrez cela, n'utilisez pas la session, ni de le mettre en lecture seule (c'est difficile à faire dans ASP.NET MVC la dernière fois que j'ai vérifié).

Mise à jour: Deux autres scénarios du monde réel où cela peut arriver:

  • Vous avez une page ASP.NET qui écrit des images à une réponse binaire. Vous faites cela parce que vous devez vérifier les autorisations ou d'autres conditions pour déterminer si et quelle image servir. Si vous avez une bande de balises d'image faisant référence à cette page dans leur SRC pour aller chercher des images, vous ne pourrez en obtenir un à la fois.
  • Vous avez une console d'administration qui vous permet de gérer les tâches. Vous souhaitez pouvoir appuyer sur un bouton et lancer les tâches sur le serveur de manière asynchrone avec les barres de progression AJAX. Si votre Ajax appelle les pages ASP lorsque vous avez une session (si vous vous référez à cela ou non), vous ne pourrez en exécuter qu'un à la fois. Je suppose que cela ressemble à l'exemple de tableau de bord, mais je suis en fait dans celui-ci et je me suis tué.

0 commentaires