Pourquoi ASP.NET MVC utilise-t-il l'état de session?

Question

Recommandé par le ASP.NET l'équipe à l'utilisation de cache au lieu de la session, nous nous sommes arrêtés à l'aide de session de travail avec le Formulaire modèle de la dernière quelques années. Nous avons donc normalement la session désactivée dans le web.config

<sessionState mode="Off" />

Mais, maintenant, quand je me suis mise à l'essai d'un ASP.NET application MVC avec ce paramètre, il déclenche une erreur dans la classe SessionStateTempDataProvider à l'intérieur du framework mvc, il m'a demandé de tourner sur l'état de la session, je l'ai fait et cela a fonctionné. En regardant la source qu'il utilise de la session:

// line 20 in SessionStateTempDataProvider.cs
Dictionary<string, object> tempDataDictionary = 
httpContext.Session[TempDataSessionStateKey] as Dictionary<string, object>; 

Alors, pourquoi ils utilisent session ici? Ce qui me manque?

========================================================

Edit Désolé ne signifie pas pour ce poste à un débat sur la session vs cache, mais plutôt dans le contexte de la ASP.NET MVC, je me demandais juste pourquoi session est utilisée ici. Dans ce blog aussi Scott Watermasysk mentionné que la désactivation de session est une bonne pratique, donc je me demandais simplement pourquoi je dois l'activer pour utiliser MVC, à partir d'ici.

Answer 1

La Session est utilisé pour le TempData magasin. TempData est un très limitées de l'état de la session qui va durer que jusqu'à la prochaine demande d'un certain utilisateur. (Édition En MVC 2+, il dure jusqu'à la prochaine lecture.) Le but de TempData consiste à stocker les données, puis faire une redirection, et d'avoir les données stockées être disponible pour l'action que vous venez d'redirigés.

À l'aide de Session pour le TempData magasin signifie que toute la mise en cache distribuée système qui a déjà poignées Session de travail pour TempData. Éviter d'utiliser directement lors de la Session TempData fera a quelques avantages. La première est que vous n'avez pas à nettoyer la Session vous-même; TempData va expirer sur ses propres.

Answer 2

Recommandé par l'équipe ASP.NET d'utiliser le cache au lieu de la session

@ Ray247, pourriez-vous fournir une référence à ce sujet? Session et Cache sont différents par nature et doivent être utilisés en fonction des exigences de l'application. Par exemple, le stockage de données spécifiques à l'utilisateur dans le cache peut entraîner un comportement indésirable. Bien sûr, si vous voulez vraiment éviter d'utiliser une session, vous pouvez fournir votre propre implémentation de l'interface ITempDataProvider .

Answer 3

Hmm ... Peut-être avez-vous entendu parler de la persistance d'objets lourds ou d'objets relativement peu utilisés - il est certainement préférable de les mettre en cache, mais pour les objets légers ou pour les données requises à chaque demande, il n'existe pas de meilleure technique que celle utilisée. mettez-les en session.

Les sessions ne sont pas mauvaises si vous les utilisez correctement.

Answer 4

Juste un additionnel de la pensée. TempData a son propre but et MS savais qu'il sera différent de l'école de pensée à l'égard de TempData persistante mécanisme. Donc, par défaut, ils ont fait de la persistance de la banque pour être SessionState. Mais la conception est encore très souple. Sur la base des besoins du projet et de la gouvernance qui la guide, vous pouvez créer votre propre tempdata fournisseur à répondre à des besoins spécifiques.

Voici quelques pointeurs vers les ressources TempData

Voici quelques améliorations supplémentaires dans la mise en œuvre TempData TempData Améliorations

Voici une autre mise en œuvre à l'aide de MS Vitesse de mise en Cache Distribuée. Vitesse TempData Fournisseur