Session vs singleton pattern

Question

Tengo una aplicación web en la que me gustaría extraer la configuración del usuario de una base de datos y almacenarla para acceso global. ¿Tendría más sentido almacenar los datos en un Singleton o un objeto Session? ¿Cuál es la diferencia entre los dos?

¿Es mejor almacenar los datos como una referencia de objeto o dividirlo en objetos de tipo de valor (Ints y cadenas)?

Answer 1

Sesión. Para eso es para eso. La sesión se almacena en el caché global (básicamente un singleton), codificado por el ID de la sesión. De esta forma, obtienes solo los datos para la sesión de interés. Usar un singleton básicamente sería replicar el caché global y tendrías que reinventar el mecanismo para recuperar datos para cada sesión de forma independiente.

Adelante y almacene el objeto. Deje que la sesión se preocupe por serializarlo en algo que pueda restaurarse. Tenga cuidado, sin embargo, con lo que pone en la sesión. No desea almacenar demasiados datos allí o va a utilizar mucha memoria (suponiendo que se trata de un caché en memoria).

Answer 2

Si se utilizan estos valores para todos los usuarios del sitio, los pusieron en un único o en caché de la aplicación. Si son específicos para cada usuario, póngalos en sesión.

referencias Uso de objetos añadidos a la aplicación o sesión de caché - Creo que los tipos de valor se consiguen en caja para que se vean como objetos a la caché. Si usa un singleton, podría ir en cualquier dirección.

Answer 3

objeto de sesión, definitivamente.

Existen singletons en el nivel de proceso. Esto significa que si tiene 20 usuarios accediendo a su sitio en un momento dado, están usando el mismo objeto singleton. Es difícil acostumbrarse a este concepto si no estás haciendo mucho desarrollo web.

Las sesiones existen en el nivel de usuario. Eso significa que puede almacenar datos por usuario, no por proceso.

Answer 4

A veces me gusta el siguiente método. Se ocupa de los problemas con cadenas mágicas y variables de sesión no establecidas. También ejecuta el singleton en el nivel de la sesión en lugar del nivel de la aplicación.

public static SessionHandler GetInstance() 
    { 
     if (HttpContext.Current.Session["SessionHandler"] == null) 
     { 
      HttpContext.Current.Session["SessionHandler"] = new SessionHandler(); 
     } 
     return (SessionHandler)HttpContext.Current.Session["SessionHandler"]; 
    } 

Entonces simplemente utilícelo como un singleton normal. Poniendo en las variables que necesitas.

Answer 5

Esto está tomado de un viejo documento, pero todavía es muy válido y funciona un convite ... Voy a poner el contenido de enlace de aquí, sobre todo porque es un viejo enlace que puede desaparecer. Taken from here.

Antecedentes

el objeto de sesión en ASP.Net se puede utilizar para almacenar información que es específica para un usuario individual del sitio. La sesión está indexada por un nombre de clave, y cuando se utiliza directamente de esa manera, puede generar una gran cantidad de nombres de sesión individuales. Un enfoque alternativo es crear un objeto singleton para agrupar elementos relacionados y almacenar ese objeto con un nombre clave dado. El "singleton" es un patrón de diseño común que especifica cómo garantizar que solo exista una única instancia de una clase en cualquier momento.

Ventajas de Singleton Sesión Objetos

• Agrupación de partidas de sesión por motivos de organización
• especialmente útil para una serie de páginas en un proceso transitorio, como el registro en un sitio. Una vez que el proceso se haya completado el objeto se puede borrar de la sesión por lo que la memoria puede ser reclamado (mejor uso de servidor recursos)
• Análisis del impacto de los cambios en la información de sesión es mucho más fácil
• identificar las áreas del sitio que son el mal uso de la información (mucho más clara que simplemente usar el nombre de la variable para determinar si es adecuado para su uso)
• Intellisense de nombres de propiedades y tipos vez acceso al objeto

desventajas de Singleton Sesión objetos

más difícil ver el número de elementos individuales en sesión resultados ASP.Net traza no muestran los valores dentro de la degradación del rendimiento cuando se utiliza objeto de almacenamiento de estado de sesión de proceso (que afecta a la serialización)

Implementación

El primer paso de implementación es crear un archivo de clase que represente la agrupación lógica de elementos que deben almacenarse juntos en el único objeto. La siguiente es una clase de ejemplo que muestra la técnica:

public class singleton 
{ 
    //Name that will be used as key for Session object 
    private const string SESSION_SINGLETON = "SINGLETON"; 

    //Variables to store the data (used to be individual 
    // session key/value pairs) 
    string lastName = ""; 
    string firstName = ""; 

    public string LastName 
    { 
    get 
    { 
     return lastName; 
    } 
    set 
    { 
     lastName = value; 
    } 
    } 

    public string FirstName 
    { 
    get 
    { 
     return firstName; 
    } 
    set 
    { 
     firstName = value; 
    } 
    } 

    //Private constructor so cannot create an instance 
    // without using the correct method. This is 
    // this is critical to properly implementing 
    // as a singleton object, objects of this 
    // class cannot be created from outside this 
    // class 
    private singleton() 
    { 
    } 

    // Create as a static method so this can be called using 
    // just the class name (no object instance is required). 
    // It simplifies other code because it will always return 
    // the single instance of this class, either newly created 
    // or from the session 
    public static singleton GetCurrentSingleton() 
    { 
    singleton oSingleton; 

    if (null == System.Web.HttpContext.Current.Session[SESSION_SINGLETON]) 
    { 
     //No current session object exists, use private constructor to 
     // create an instance, place it into the session 
     oSingleton = new singleton(); 
     System.Web.HttpContext.Current.Session[SESSION_SINGLETON] = oSingleton; 
    } 
    else 
    { 
     //Retrieve the already instance that was already created 
     oSingleton = (singleton)System.Web.HttpContext.Current.Session[SESSION_SINGLETON]; 
    } 

    //Return the single instance of this class that was stored in the session 
    return oSingleton; 
    } 
} 

Una página que quiere utilizar este objeto, simplemente hace lo siguiente:

singleton oSingleton = singleton.GetCurrentSingleton(); 
oSingleton.FirstName = "Robert"; 
oSingleton.LastName = "Boedigheimer"; 

Normalmente esta técnica almacenará muchas más variables en la clase dada o se usará para una serie de páginas web que realizan un proceso. Otra ventaja de usar esto para un proceso en un sitio web es que toda la memoria requerida para las variables de sesión se puede eliminar simplemente eliminando la referencia al objeto singleton. La clase puede implementar un método que los clientes pueden utilizar para borrar la referencia, que puede ser nombrado Dispose() para seguir el patrón típico .Net cuando una clase proporciona una forma de limpieza:

public static void Dispose() 
{ 
    //Cleanup this object so that GC can reclaim space 
    System.Web.HttpContext.Current.Session.Remove(SESSION_SINGLETON); 
} 

Conclusión

Existen muchas ventajas en el uso de objetos singleton almacenados en el objeto Session en lugar de utilizar claves de sesión individuales para almacenar información. Es útil para objetos que deben existir para toda la sesión (agrupación de elementos lógicos, análisis de impacto, intellisense, etc.) y especialmente para objetos que realmente solo son necesarios durante un período de tiempo en un sitio web hasta que el usuario completa un determinado proceso (es mucho más fácil identificar el mal uso de las variables y conservar los recursos cuando se completa el proceso, pero la sesión continuará).