Pourquoi ASP.NET MVC utiliser l'état de session?

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 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?

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

Modifier 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 post de 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.

  • Pourriez-vous fournir un lien à l'endroit où ils disent "utiliser cache à la place de sessions" , la cause, ils ne sont pas vraiment conçus pour la même chose?
  • Si je me souviens bien je l'ai lu dans le numéro de septembre 2005 de la MSDN magazine. Peut-être que je devrais mot de son mieux, mais nous n'avons tout simplement pas utiliser de session tout à fait.
  • Il a dit: "Conseil: Désactiver l'état de session lorsque vous n'utilisez pas.", il est rare que les sessions ne sont pas utilisés dans un authentifié de la zone.
  • Fourni Scott lien ne fonctionne plus.
  • fixe.
  • En aparté, l'article sur l'état de session trouvé dans le numéro de septembre 2005 de MSDN magazine peut être lu ici - s'il vous plaît noter qu'il se réfère à une version préliminaire de ASP.NET 2.0

InformationsquelleAutor Ray | 2008-12-22
  1. 33

    De 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. (Modifier 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é.

    À 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.

    • Comment cela fonctionne dans un tournoi à la ronde web de configuration de batterie de serveurs? Est-il un moyen de désactiver l'État de Session/TempData MVC?
    • Il fonctionne de la même façon que la session fonctionne toujours sur une batterie de serveurs. Ceci est documenté sur le site MSDN. Le meilleur moyen est d'utiliser un cache distribué, mais vous pouvez également utiliser des "sessions pense-bête." Concernant la désactivation de session, encore une fois, c'est juste comme n'importe quel autre ASP.NET application. Voir MSDN. Ensuite, il suffit de ne pas utiliser TempData. Cela dit, c'est comme guérir l'acné par décapitation.
    • L'état de Session peut être désactivé, en désactivant dans le web.de configuration et de mise en œuvre de la ITempDataProvider interface.
    • Putain vous. Écrit juste une question et trouve ici une réponse lorsque cette option est cochée, une fois de plus pour les doublons. Gaspillé ~15 minutes... xD
    • quand et comment cette session permettra d'obtenir effacée..?
    • Santose: MVC 1, sur la demande suivante. Dans MVC 2 beta +, lors de la lecture.
    • Craig, vous pouvez modifier votre réponse pour MVC 2+ (comme vous l'avez dans le commentaire ci-dessus). Les gens de lire votre réponse et de sauter cette partie
    • OK, c'est fait.

    InformationsquelleAutor Craig Stuntz
  2. 13

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

    @ray247, pourriez-vous fournir une référence pour le présent? Session et le Cache sont différents par nature et doivent être utilisés selon les exigences de l'application. Par exemple l'utilisateur de stockage des données spécifiques dans le cache pourrait conduire à un comportement indésirable. Bien sûr, si vous voulez vraiment éviter à l'aide de session vous pouvez fournir votre propre mise en œuvre de la ITempDataProvider interface.

    • voir mon précédent commentaire
    • btw, pourquoi stoing spécifique à l'utilisateur, les données dans le cache pourrait conduire à un comportement indésirable? Si vous avez obtenu la clé de cache correctement pour chaque utilisateur, je ne vois pas en quoi c'est un problème.
    • Parce que le cache est par définition instable. Il y a des situations en dehors de votre contrôle, telles que la mémoire de la pression dans lequel le cache pourrait invalidé et donc de perdre toutes les données de session.
    • "Par défaut, ASP.NET les applications de stocker l'état de session dans la mémoire du processus de travail, en particulier dans le privé, emplacement de l'objet dans le Cache." - MSDN (msdn.microsoft.com/en-us/library/aa479041.aspx)
    InformationsquelleAutor Darin Dimitrov
  3. 6

    Hmm... Peut-être que vous avez lu au sujet de la persistance des objets lourds ou relativement rarement accessible objets - c'est certainement mieux pour les mettre en cache, mais pour des objets légers ou de données qui est nécessaire à chaque demande il n'y a pas de meilleure technique que de les mettre dans la Session.

    Les séances ne sont pas mal si vous les utilisez correctement.

    • C'est une vieille question, mais cette réponse (et à un moindre degré, tous les autres aussi) ignore le fait que l'OP a l'aide d'un WebFarm de l'infrastructure, ce qui implique dans l'aide de SQL Server (qui est assez lent pour que la tâche) ou d'un dédié, partagé sur le réseau de service de windows (qui est une douleur dans le**) pour le maintien de cette session - si la mise en cache serait probablement un meilleur choix en effet.
    InformationsquelleAutor maxnk
  4. 3

    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

    InformationsquelleAutor rajesh pillai