c# - Campos estáticos vs variables de sesión

asp.net .net

Question

Hasta ahora he estado usando Session para pasar algunas variables de una página a otra. Por ejemplo, rol de usuario. Cuando un usuario inicia sesión en la aplicación web, el ID de rol del usuario se mantiene en Sesión y ese rol se verifica en diferentes partes de la aplicación. Recientemente comencé a pensar por qué no usar miembros estáticos. Puedo almacenar la misma información en un campo estático y acceder fácilmente a ella en cualquier lugar de mi aplicación (en cualquier lugar se incluye el espacio de nombres en el que reside ese campo estático). Sé que usar las variables de Sesión a veces es útil, de manera que:

1. Cualquier tipo de datos se pueden almacenar en la sesión. Sin embargo, se debe convertir. Sin embargo, los campos estáticos solo aceptan datos con el tipo de datos correcto.
2. Las variables de sesión caducarán después de un cierto tiempo, que es el comportamiento que necesitamos en muchos casos.

Aparte de lo anterior, ¿existen otras razones por las que no deba usar campos estáticos para almacenar datos y tenerlos disponibles en todas partes?

Answer 1

Los campos estáticos se compartirían entre todos los usuarios.
En un entorno web, tendrá varios subprocesos ejecutándose juntos.

La actualización de cualquier miembro estático necesitaría un control de concurrencia adecuado. Hecho mal, esto ralentizaría significativamente el rendimiento de su sitio.

Las sesiones se pueden mover fuera de proceso y compartir en una granja de servidores web.

Las sesiones fuera de proceso existirían incluso si su servidor de aplicaciones fallara.

Answer 2

No, usar variables estáticas para esto no es el camino a seguir:

• Si su dominio de aplicación se recicla, todas sus variables estáticas se "restablecerán"
• Las variables estáticas no se escalan horizontalmente: si equilibra la carga de su aplicación, un usuario que golpea un servidor y luego otro diferente no verá el almacén de datos en las variables estáticas del primer servidor.
• Lo más importante es que las variables estáticas serán compartidas por todos los accesos a ese servidor ... no será para cada usuario en absoluto ... mientras que para su descripción, no querrá que el usuario X vea la información del usuario Y .

Fundamentalmente, tiene dos opciones para propagar información en torno a su aplicación:

• Manténgalo en el lado del cliente, de modo que cada solicitud proporcione la información de los pasos anteriores. (Esto puede volverse difícil de manejar con grandes cantidades de información, pero puede ser útil para casos simples).
• Manténgalo en el lado del servidor, idealmente de alguna manera persistente (como una base de datos) con el cliente proporcionando un identificador de sesión.

Si puede usar el equilibrio de carga para mantener a todos los usuarios en el mismo servidor, y si no le importa que las sesiones se pierdan cuando se recicle el dominio de aplicación ¹ o que se caiga un servidor, puede mantenerlo en la memoria. ... Pero ten cuidado.

¹ Puede haber mecanismos en ASP.NET para sobrevivir a esto, propagando la información de la sesión de un dominio de aplicación a otro. No estoy seguro

Answer 3

Olvidas una cosa (creo)

Los datos estáticos serán los mismos para todos los usuarios de la aplicación, mientras que la sesión es "por usuario".

Así que para su escenario de "Función de usuario", esperaría resultados graciosos;)

Answer 4

Son dos cosas muy diferentes.

• La sesión se puede usar fuera de proceso (importante para el equilibrio de carga)
• La sesión puede ser más duradera debido a sus capacidades fuera de proceso.
• ASP.Net gestiona automáticamente la concurrencia de sesión.
• El acceso a las variables estáticas debe ser sincronizado manualmente.
• Static es global para todo el dominio de la aplicación. Si establece el valor de un campo / propiedad estática para un usuario, todos los usuarios obtendrán el mismo valor. No es el comportamiento deseado en su escenario.

Cualquier tipo de datos se pueden almacenar en la sesión. Sin embargo, se debe convertir. Sin embargo, los campos estáticos solo aceptan datos con el tipo de datos correcto.

A menudo es útil abstraer los valores de sesión con una clase auxiliar. Esto puede mejorar la capacidad de prueba y también le permite escribir propiedades y realizar el reparto en las partes internas de la clase.

Ejemplo:

public List<int> UserRoles
{
    get
    {
        // optionally check that the value is indeed in session, otherwise this 
        // will throw
        return (List<int>)Session["UserRoles"];
    }
}

Ver también:

• Variables estáticas de C # - alcance y persistencia
• aspx proporciona un tratamiento especial para las variables estáticas c #