Persistendo / caching dei dati tra le richieste - approccio comune

Question

Sto sviluppando un Asp.net (MVC, ma questo non ha molta importanza) applicazione. Ho un personalizzato IHttpModule che è responsabile per la PostAuthenticateRequest per cambiare utente principale e identità.

Sono la memorizzazione UserID e UserName nel cookie di autenticazione quando i log-in dell'utente. Ho un IUSER (implementato da DAO e Business Objects strati, ciascuno con i propri membri supplementari) che ho bisogno in tutto le classi di servizi alle imprese. Quando un utente vuole qualche cosa devo fornire istanza dell'oggetto IUSER (di solito da Business Objects strato) in modo che fornisce ID dal ticket autenticazione non è sufficiente.

Così sto pensando a come e dove sarebbe meglio a persistere loggato dati IUSER degli utenti?

1. Non voglio andare a prendere ogni volta dal DB (in base ai dati UserID del ticket di autenticazione)
2. Non riesco a conservarlo in Sessione da quando devo lavorare all'interno PostAuthenticateRequest, dove sessione non è ancora pronto
3. Voglio tutte le funzionalità per essere incapsulato all'interno di mia abitudine IHttpModule

Scelte che vedo:

• Cache
• Cookie
• (Session) - passando da PostAuthenticateRequest all'evento PostAcquireRequestState e il cambiamento principale / identità lì, ma vorrei evitare questo

I processi che sembrano complicare le cose sono:

1. log-in utente, dati utente prelevato dalla DB e persisteva in qualche modo per richieste successive
2. utente si disconnette-out, i dati utente deve essere rimosso dal supporto persistente automagicamente
3. modifiche utente proprio profilo, dati utente deve essere eliminata e rileggere su richiesta successiva dal DB

I wan't tutti questi per essere gestite automaticamente dal modulo Http (se possibile) per eliminare gli errori dello sviluppatore di dimenticare di resettare queste cose.

Quello che inoltre non voglio è quello di scrivere / leggere alcune variabili / chiavi hardcoded e manipolarle in altre parti dell'applicazione. Ciò presenterebbe solo debito tecnico.

Domande

1. Che cosa suggerisce?
2. Come fa i dati dell'utente tra le richieste?

Answer 1

Dato le vostre esigenze, suppongo che la soluzione migliore è quella di recuperare l'ID dal cookie e utilizzarlo per indicizzare il Http Cache (HttpContext.Current.Cache).

Se si desidera mantenere come gli utenti accedono, avvolgere il cache in un oggetto "UserCache". L'oggetto potrebbe essere costruito da un modulo Http e memorizzata come (l'aspetti ...) Singleton all'interno della cache stessa o, meglio ancora, basta costruito quando necessario per tirare dalla cache http. Ciò dipende da dove è necessario accedervi e se HttpContext.Current.Cache è direttamente disponibile. L'implementazione pigro è al di sotto.

Ancora una volta, questo è per chiarezza e non è come mi piacerebbe davvero attuarla.

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(/* ... */);
  }
}

Utilizzando i meccanismi di default di caching (o meglio ancora un meccanismo di caching fornito da DI in modo che non siete legati ad un'implementazione), è possibile impostare una scadenza per rimuovere automaticamente gli utenti dalla cache come indicato nel commento. È possibile impostare la cache di essere dipendente da aggiornamenti del server SQL, nonché per gestire gli aggiornamenti o aggiornare manualmente come parte del servizio per salvare le modifiche.

Maggiori informazioni sulla cache di default è disponibile qui . Maggiori informazioni su cache di dipendenze è disponibile < a href = "http://msdn.microsoft.com/en-us/library/system.web.caching.cachedependency.aspx" rel = "nofollow noreferrer"> qui .

Nel HttpModule stesso, suppongo che si possa fare un po 'di magia in caso EndRequest per vedere se la richiesta viene autenticato e quindi accedere l'utente sulla base di cookie, ma non sono sicuro se questo avrebbe funzionato come ho' ve mai provato. Si potrebbe desiderare di avere uno sguardo a questo articolo su MSDN da via del ritorno nei giorni 1,1 e vedere se risponde ad alcune delle problematiche che si sta tentando di risolvere.

Per quanto riguarda l'architettura SO e come lo fanno, mi immagino che caricano quando necessario perché tengono la maggior parte della banca dati nella RAM in ogni momento ( http://highscalability.com/stack-overflow-architecture ).