Persistiendo / almacenamiento en caché de datos entre las peticiones - enfoque común

Question

Estoy desarrollando un Asp.net (MVC pero esto no tiene importancia) de la aplicación. Tengo un encargo IHttpModule que es responsable de la PostAuthenticateRequest para cambiar directora y la identidad del usuario.

Estoy almacenando ID de usuario y nombre de usuario en la cookie de autenticación cuando el usuario los registros de entrada. Tengo una IUser (implementado por DAO y Business Objects capas, cada una con sus propios miembros adicionales) que necesito toda clases de servicio de negocio. Cuando un usuario quiere nada tengo que proporcionar IUser instancia de objeto (por lo general de Business Objects capa) para proporcionar ID del ticket de autenticación no es suficiente.

Así que estoy pensando en cómo y dónde sería mejor persisten conectado datos IUSER de usuario?

1. No quiero a buscarla cada vez desde el DB (basado en los datos de UserID vale de autenticación)
2. No se puede almacenar en la sesión ya que tengo que trabajar dentro PostAuthenticateRequest, donde Sesión aún no está listo
3. Quiero toda la funcionalidad para encapsular dentro de mi costumbre IHttpModule

Las opciones que veo:

• Cache
• Cookie
• (Sesión) - al pasar de PostAuthenticateRequest al evento PostAcquireRequestState y el cambio director / identidad allí, pero me gustaría evitar este

Los procesos que parecen complicar las cosas son:

1. logs-IN de usuario, los datos de usuario se descargue de la DB y persistió algún modo para solicitudes posteriores
2. usuario inicia una sesión de salida, datos de usuario tiene que ser eliminado a partir de medio PERSISTED automágicamente
3. cambios de usuario propio perfil, datos de usuario tiene que ser descartados y releer en la siguiente solicitud de la DB

Me wa todo esto a ser manejados automáticamente por HttpModule (si es posible) para eliminar los errores de los desarrolladores de olvidarse de restablecer estas cosas.

Lo que tampoco quiero es escribir / leer algunas variables / llaves codificadas y manipularlos en otras partes de la aplicación. Esto sólo presentaría deuda técnica.

Preguntas

1. ¿Qué sugieres?
2. ¿Cómo persistir lo que los datos de usuario entre las solicitudes?

Answer 1

Teniendo en cuenta sus necesidades, supongo que la mejor solución es recuperar el ID de la cookie y lo utilizan para indexar en la caché HTTP (HttpContext.Current.Cache).

Si se quiere mantener la forma en que los usuarios acceden, envolver el caché en un objeto "UserCache". El objeto podría ser construido por un HttpModule y se almacena como un (esperar a que ...) Singleton dentro de la propia caché o, mejor aún, el recién construido cuando sea necesario para tirar de la memoria caché HTTP. Esto depende de dónde se necesita para acceder a ella y si HttpContext.Current.Cache está directamente disponible. La aplicación es perezosa a continuación.

Una vez más, esto es para la claridad y no es la forma en que me realmente ponerlo en práctica.

public class UserCache
{
  public IUser GetUser(object userKey)
  {
    return HttpContext.Current.Cache[userKey];
  }

  public void AddUser(object userKey, IUser user)
  {
    /* this could pull the key from the user object as well. */
    HttpContext.Current.Cache.Add(/* add the object with key and a sliding expiration that is slightly greater than session timeout */);
  }

  public void ExpireUser(object userKey)
  {
    HttpContext.Current.Cache.Remove(userKey);
  }

  /* If you don't want to do SQL cache dependency */
  public void UpdateUser(object userKey, IUser user)
  {
    HttpContext.Current.Cache.Insert(/* ... */);
  }
}

El uso de los mecanismos de caché por defecto (o mejor aún un mecanismo de almacenamiento en caché DI suministrada por lo que no está atado a una aplicación), se puede establecer una fecha de caducidad para eliminar automáticamente a los usuarios de la caché como se menciona en el comentario. Puede configurar el caché de ser dependiente de las actualizaciones del servidor SQL, así manejar las actualizaciones manualmente o actualizarlo como parte del servicio para guardar los cambios.

Más información sobre el caché por defecto está disponible aquí . Más información sobre caché dependencias está disponible < a href = "http://msdn.microsoft.com/en-us/library/system.web.caching.cachedependency.aspx" rel = "nofollow noreferrer"> aquí .

En la propia HttpModule, supongo que se podría hacer un poco de magia en caso EndRequest para ver si la petición es autenticada y luego ingrese el usuario en base a la galleta, pero no estoy seguro de si eso funcionaría como yo' nunca he probado. Es posible que desee echar un vistazo a este artículo en MSDN de tiempo atrás en los 1,1 días y ver si responde a algunos de los problemas que están tratando de resolver.

En cuanto a la arquitectura de SO y cómo lo hacen, me imagino que lo cargan cuando es necesario, ya que mantener la mayor parte de la base de datos en la memoria RAM en todo momento ( http://highscalability.com/stack-overflow-architecture ).