asp.net-mvc - programacion - asp.net tutorial

¿Por qué ASP.NET MVC usaría estado de sesión?

Question

Recomendado por el equipo de ASP.NET para usar el caché en lugar de la sesión, dejamos de utilizar la sesión para trabajar con el modelo de WebForm en los últimos años. Por lo tanto, normalmente tenemos la sesión desactivada en la web.config

<sessionState mode="Off" />

Pero ahora, cuando estoy probando una aplicación ASP.NET MVC con esta configuración, arroja un error en la clase SessionStateTempDataProvider dentro del framework SessionStateTempDataProvider , me pide que active el estado de la sesión, lo hice y funcionó. Mirando la fuente, usa la sesión:

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

Entonces, ¿por qué usarían la sesión aquí? ¿Qué me estoy perdiendo?

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

Editar Lo siento no significaba que esta publicación debatiera sobre la sesión frente al caché, sino más bien en el contexto de ASP.NET MVC, me preguntaba por qué la sesión se usa aquí. En esta publicación de blog también Scott Watermasysk mencionó que desactivar la sesión es una buena práctica, así que me pregunto por qué tengo que activar MVC a partir de ahora.

Answer 1

Recomendado por el equipo de ASP.NET para usar el caché en lugar de la sesión

@ ray247, ¿podría proporcionar una referencia para esto? La sesión y la memoria caché son diferentes por naturaleza y deben usarse según los requisitos de la aplicación. Por ejemplo, almacenar datos específicos del usuario en el caché podría conducir a un comportamiento no deseado. Por supuesto, si realmente desea evitar el uso de la sesión, puede proporcionar su propia implementación de la interfaz ITempDataProvider .

Answer 2

Hmm ... Puede que haya leído sobre la persistencia de objetos pesados ​​u objetos a los que se accede con relativa poca frecuencia; definitivamente es mejor colocarlos en el caché, pero para objetos ligeros o datos necesarios en cada solicitud no hay mejor técnica que ponerlos en la sesión.

Las sesiones no son malas si las estás usando correctamente.

Answer 3

Solo un pensamiento adicional. TempData tiene su propio propósito y MS sabía que habría diferentes escuelas de pensamiento con respecto al mecanismo persistente TempData. Por lo tanto, de forma predeterminada hicieron que la tienda persistente fuera SessionState. Pero el diseño sigue siendo muy flexible. En función de las necesidades del proyecto y la gobernanza que lo guía, puede crear su propio proveedor de tempdata para satisfacer requisitos específicos.

Aquí hay algunos consejos para los recursos TempData

Aquí hay algunas mejoras adicionales en la implementación de TempData Mejoras de TempData

Aquí hay una implementación alternativa usando el almacenamiento en caché distribuido de MS Velocity. Proveedor Velocity TempData

Answer 4

La sesión se usa para la tienda TempData. TempData es una forma muy limitada de estado de sesión que durará solo hasta la próxima solicitud de un determinado usuario. ( Editar en MVC 2+, dura hasta que se lea a continuación). El objetivo de TempData es almacenar datos, luego hacer un redireccionamiento y tener los datos almacenados disponibles para la acción a la que acaba de redirigir.

Usar Session para la tienda TempData significa que cualquier sistema de caché distribuido que ya maneje Session funcionará para TempData. Evitar el uso de Session directamente cuando lo haga TempData tiene un par de ventajas. Una es que no tiene que limpiar la sesión usted mismo; TempData "caducará" por sí mismo.