asp.net - tutorial - mvc c# windows forms

¿Es una buena práctica evitar el uso del estado de sesión en ASP.NET MVC? Si es así, ¿por qué y cómo? (8)

No está escrito explícitamente en alguna parte, pero lo sentí después de leer algunos blogs en ASP.NET MVC. Solo me puse curioso y pensé en preguntarlo aquí.

ACTUALIZAR:
No estoy preguntando sobre preocupaciones de memoria / almacenamiento / RAM en el servidor. Para ellos, hay una solución para almacenar la sesión fuera de proceso. Yo sé eso. Tengo curiosidad de que, ¿hay escenarios en los que tuvimos que usar Session en WebForms pero ahora podemos evitarlo en MVC aprovechando la buena forma estructurada que ofrece MVC?

¿Qué significaría evitar usar Session State para usted? ¿Necesita almacenar cómodamente pequeñas cantidades de datos de usuario a través de las solicitudes? Si es así, ¿cómo lo harías?

No estoy seguro de cuáles serían sus alternativas al estado de la sesión. Usar Session State tal como existe, en ASP.NET es mucho más deseable para lanzar su propia alternativa, especialmente desde una perspectiva de seguridad.

En ASP.NET Web Forms, pasar información entre diferentes páginas nunca fue especialmente fácil sin el uso de la sesión. Debido al modelo centrado en la devolución de datos, la información estaba disponible en el servidor como parte de un evento, pero a menudo en la página incorrecta para mostrar un resultado, por lo que es necesario pasar la información entre las páginas.

Esto tendió a conducir a un uso excesivo de la sesión, llenando las variables "actuales" en sesión con la intención de indicar con qué era el objeto actual con el que interactuaba. Este uso excesivo a su vez hizo que las aplicaciones dependieran mucho del estado y mucho más difícil determinar el comportamiento esperado ("¿Esta variable está poblada?" "¿Ya tengo el ID de pedido actual?").

MVC está estructurado en torno a la idea de que su sitio web es una vista hacia un modelo lógico de información. Se alienta a tener operaciones sin estado mediante el uso de controladores simples que responden a acciones con información clave aprobada como parte de la solicitud HTTP.

Debido a estas propiedades, la sesión ya no es necesaria para realizar tareas básicas en MVC, y se adapta mal donde antes parecía una opción perfectamente válida.

Fundamentalmente, la sesión contamina HTTP . Hace que las solicitudes (que a menudo contienen su propio estado) dependan del estado interno del servidor receptor. Es por eso que se lo ve como algo maligno (aunque a menudo práctico y necesario).

La administración de sesiones siempre fue desafiante desde los formularios web de ASP.net hasta ASP.NET MVC. Sin embargo, MVC alienta a tratarlo como sin estado ya que tiene el beneficio de la API web basada en REST . La mayoría de las cosas que usamos para almacenar en Session anteriormente se lograron mediante el uso de la combinación de MVC + Web API.

La caducidad de la sesión por lo general no corresponde a la intención del usuario (por ejemplo, si IIS se recicla, se pierde el estado de la sesión de proceso). Lo único que creo que puede ser útil es el almacenamiento en memoria caché de los datos del usuario, y no la fuente autorizada de la verdad (que probablemente debería ser DB).

Realmente depende de la cantidad de datos que mantiene en el estado de la sesión. Como regla general, trato de usarlo solo por algunas cuerdas aquí y allá y no mucho más. Para un formulario grande, por ejemplo, podría almacenar un ID de referencia para esa sesión, luego almacenar todos los datos necesarios en tablas temporales SQL basadas en ese ID. Es un poco doloroso, pero el estado de la sesión no está destinado a ser utilizado para almacenar mucha información.

Se evitó la sesión incluso antes de MVC, porque es información que persiste en el servidor para cada uno de los usuarios que se conectan a su aplicación y (a diferencia de la caché) no se borra automáticamente cuando no se utiliza.

También para ayudarlo a evitar el uso de la sesión, ASP.NET tenía viewstate, que en realidad era un gran campo oculto en sus formularios web que se PUBLICAN en cada devolución. Esto también fue demasiado torpe por varias razones y se eliminó con MVC.

Entonces la sesión es algo que no era muy recomendable incluso antes de MVC. La razón es principalmente escalabilidad. Mientras menos estado tengas, más escalable será tu sitio. Si no le importa la escalabilidad (por lo que sé que podría estar desarrollando una aplicación de intranet para 200 usuarios) o si tiene muy poca información para persistir, use la sesión. En otros casos, usar sesión es totalmente apropiado: un escenario típico donde se usa el estado de sesión es el carrito de compras en un sitio de comercio electrónico (información que es inherentemente por usuario por sesión y que solo un porcentaje de sus usuarios realmente se ha llenado).

En cuanto a las alternativas, no hay un reemplazo directo y directo para la sesión. Dependiendo de lo que trates de hacer, es posible que puedas usar el caché o las cookies. MVC no ha traído nada particularmente nuevo en ese sentido, AFAIK.

Agregar a respuestas anteriores

Las sesiones son generalmente malvadas en términos de aplicaciones modernas y la aplicación moderna aquí se aplica principalmente a las aplicaciones centradas en la nube, pero depende enormemente de dónde las almacenemos.

Independientemente de ASP.NET WebForms o ASP.NET MVC, generalmente con sesión, imaginamos un carrito de compras con el carrito lleno o eliminado que se mantiene a lo largo de cómo se mantiene realmente la sesión. Así que esta era una forma fácil y barata de hacer las cosas, por lo general la sesión reside en

InProc
StateServer
Servidor SQL
Ahora en caché distribuida más detalles

HTTP by birth no tiene estado, por lo que cuando queremos ampliar horizontalmente la aplicación agregamos nodos a nivel web u otros niveles, por lo que ahora el problema es qué nodo atenderá la solicitud del usuario actual. depende enormemente del equilibrador de carga que tiene diferentes modos de equilibrar.

Por lo tanto, múltiples nodos pueden servir para el mismo usuario dependiendo de loadbalancer, pero podemos anular con una sesión fija en el nivel web lo que asegurará que el usuario actual use los mismos nodos, que falla al escalar la aplicación, ejemplo clásico consideramos que tenemos 1,000 sesiones activas en cada 2 nodos y ahora agregamos un nodo más, generalmente esperamos que 3 nodos compartan casi el mismo número de sesiones, pero eso falla porque esos 1,000 deben estar activos en nodos particulares porque estamos usando sesiones adhesivas, el escalado llevará tiempo hasta que esas sesiones sean despejado.

Una vez más, ¿y si queremos ampliar o revertir la aplicación de escala? o uno o más servidores se caen, los datos de la sesión completa se perderán si mantenemos la sesión en InProc o StateServer e incluso cuando los nodos de nivel web cambian para el mismo usuario, mientras que si almacenamos en SQLServer está bien pero generalmente es lento, entonces la respuesta aquí parece ser un caché distribuido que es rápido y puede hacerse confiable.

Use TempData lugar de HttpSessionState . TempData es el contenedor de Mvc del estado de la sesión.