Qué poner en una variable de sesión

Question

Recientemente me encontré con una aplicación web ASP 1.1 que colocaba un montón de cosas en la variable de sesión, incluidos todos los objetos de datos de la base de datos e incluso el objeto de conexión de la base de datos.Termina siendo enorme.Cuando la sesión web se agota (cuatro horas después de que el usuario haya terminado de usar la aplicación), a veces las transacciones de su base de datos se revierten.Supongo que esto se debe a que la conexión a la base de datos no se cierra correctamente cuando IIS finaliza la sesión.

De todos modos, mi pregunta es ¿qué debería estar en la variable de sesión?Es evidente que algunas cosas deben estar ahí.El usuario selecciona qué plan desea editar en la pantalla principal, por lo que la identificación del plan ingresa en la variable de sesión.¿Es mejor intentar reducir la carga en la base de datos almacenando todos los detalles sobre el usuario (y su administrador, etc.) y el plan que están editando en la variable de sesión o debería intentar minimizar las cosas en la variable de sesión y ¿Consultar la base de datos para todo lo que necesito en el evento Page_Load?

Answer 1

Esto es bastante difícil de responder porque es muy específico de la aplicación, pero aquí hay algunas pautas que utilizo:

1. Pon lo menos posible en la sesión.
2. Las selecciones específicas del usuario que solo deberían durar durante una visita determinada son una buena opción.
3. A menudo, las variables que deben ser accesibles para varias páginas durante la visita del usuario a su sitio (para evitar pasarlas de una página a otra) también son buenas para incluir en la sesión.

Por lo poco que ha dicho sobre su aplicación, probablemente seleccionaría sus datos de la base de datos e intentaría encontrar formas de minimizar el impacto de esas consultas en lugar de cargar la sesión.

Answer 2

Hacer no poner información de conexión de base de datos en la sesión.

En cuanto al almacenamiento en caché, evitaría usar la sesión para el almacenamiento en caché si es posible; se encontrará con problemas cuando alguien más cambie los datos que está usando un usuario, además no podrá compartir los datos almacenados en caché entre usuarios.Utilice ASP.NET Cache o alguna otra utilidad de almacenamiento en caché (como Memcached o Velocity).

En cuanto a qué debería ir a la sesión, cualquier cosa que se aplique a todo Las ventanas del navegador que un usuario tiene abiertas en su sitio (inicio de sesión, configuración de seguridad, etc.) deben estar en la sesión.Cosas como qué objeto se está viendo/editando realmente deberían ser variables GET/POST que se pasan entre las pantallas para que un usuario pueda usar múltiples ventanas del navegador para trabajar con su aplicación (a menos que desee evitarlo).

Answer 3

NO poner objetos de UI en sesión.

Más allá de eso, diría que varía.demasiada sesión puede ralentizarlo si no está utilizando la sesión en proceso porque va a serializar mucho + la velocidad del proveedor.Cache y Session deben usarse con moderación y cuidado.No inicies sesión simplemente porque puedes o te conviene.Siéntate y analiza si tiene sentido.

Answer 4

Idealmente, la sesión en ASP debería almacenar la menor cantidad de datos posible.Almacenar una referencia a cualquier objeto que mantenga abiertos los recursos del sistema (particularmente una conexión de base de datos) definitivamente elimina la escalabilidad.Además, almacenar datos no confirmados en una variable de sesión es una mala idea en la mayoría de los casos.En general, parece que la implementación actual utiliza de manera abusiva objetos de sesión para intentar simular una aplicación con estado en un entorno supuestamente sin estado.

Aunque es muy difamado, el modelo ASP.NET de administrar el estado automáticamente a través de campos ocultos realmente debería eliminar la mayor parte de la necesidad de mantener algo en las variables de sesión.

Mi regla general es que cuanto más escalable (en términos de usuarios/accesos) debe ser la aplicación, menos podrá salirse con la suya usando el estado de sesión.Sin embargo, existe una compensación.Para las aplicaciones web en las que el usuario accede repetidamente a los mismos datos y normalmente tiene una sesión bastante larga por uso del sitio, algo de almacenamiento en caché (si es necesario en los objetos de la sesión) puede ayudar a la escalabilidad al reducir la carga en el servidor de base de datos.La idea aquí es que es mucho más barato y menos complejo cultivar la capa de presentación que la base de datos back-end.Por supuesto, en todo caso, este consejo debe tomarse con moderación y no se aplica en todas las situaciones, pero para una aplicación CRUD interna bastante simple, debería serle de gran utilidad.

Answer 5

A pregunta muy similar Se le preguntó anteriormente sobre las sesiones de PHP.Básicamente, las sesiones son un excelente lugar para almacenar datos específicos del usuario a los que necesita acceder a través de varias cargas de páginas.Las sesiones NO son un buen lugar para almacenar referencias de conexión a bases de datos;Sería mejor utilizar algún tipo de software de agrupación de conexiones o abrir/cerrar su conexión en cada carga de página.En cuanto al almacenamiento en caché de los datos de la sesión, esto depende de cómo se almacenan los datos de la sesión, cuánta seguridad necesita y si los datos son específicos del usuario o no.Una mejor opción sería utilizar otra cosa para almacenar datos en caché.

Answer 6

almacenar señales de navegación en sesiones es complicado.El mismo usuario puede tener varias ventanas abiertas y luego los cambios se propagan de forma confusa.Las conexiones DB deben definitivamente no ser almacenado.ASP.NET mantiene el grupo de conexiones por usted, sin necesidad de recurrir a su propia brujería.Si necesita almacenar en caché cosas durante períodos cortos y el tamaño del conjunto de datos es relativamente pequeño, considere ViewState como una posible opción (a costa de cargar más volumen en el tamaño de la página)

Answer 7

A:Datos que son sólo relativos a un usuario.ES DECIR:un nombre de usuario, una identificación de usuario.En mayoría un objeto que representa a un usuario.A veces, los datos relativos a la URL (como dónde llevar a alguien) o una pila de mensajes de error son útiles para insertar en la sesión.

Si desea compartir cosas potencialmente entre diferentes usuarios, utilice la tienda de aplicaciones o la caché.Son muy superiores.

Answer 8

Esteban,
¿Trabaja para una empresa que comienza con "I", que tiene un sitio web que comienza con "BC"?Eso suena exactamente como lo que hice cuando comencé a desarrollar en .net (y era joven y estúpido): llené todo lo que se me ocurrió en la sesión y la aplicación.No hace falta decir que eso fue doblemente malo.
En general, evite las sesiones tanto como sea posible.Ciertamente, los objetos no serializables no deberían almacenarse allí (conexiones de bases de datos y demás), pero ni siquiera los objetos grandes serializables deberían almacenarse allí.Simplemente no quieres los gastos generales.

Answer 9

Siempre mantendría muy poca información en la sesión.Las sesiones utilizan recursos de memoria del servidor, lo cual es costoso.Guardar demasiados valores en la sesión aumenta la carga en el servidor y eventualmente el rendimiento del sitio disminuirá.Cuando utiliza servidores de equilibrio de carga, el uso de la sesión puede generar problemas.Entonces lo que hago es usar sesiones mínimas o nulas, usar cookies si la información no es muy crítica, usar más campos ocultos y sesiones de bases de datos.