Dati persistenti/di memorizzazione nella cache tra le richieste - approccio comune

Question

Sto sviluppando un'applicazione Asp.net (MVC ma non importa). Ho un modulo IHHT personalizzato che è responsabile di PostAuthenticateRequest per modificare l'identità dell'entità utente &.

Sto memorizzando UserID e UserName nel cookie di autenticazione quando l'utente effettua il login. Ho un IUser (implementato dal livello DAO e Business Objects, ciascuno con i propri membri aggiuntivi) che ho bisogno di tutte le classi di servizi aziendali. Quando un utente vuole qualcosa, devo fornire l'istanza dell'oggetto IUser (di solito dal livello Business Objects) in modo che l'ID del ticket di autenticazione non sia sufficiente.

Quindi sto pensando a come e dove sarebbe meglio mantenere i dati IUser dell'utente registrati?

1. Non voglio andare a prendere ogni volta dal DB (in base ai dati UserID del ticket di autenticazione)
2. non posso conservarla in Sessione da quando devo lavorare all'interno PostAuthenticateRequest, dove isn Session' t 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

processi che sembrano complicare le cose sono:

1. log-in utente, dati utente prelevato dalla DB e persistito in qualche modo per la successiva richiede
2. utente si disconnette-out, i dati utente deve essere rimosso dal persistito automagiche medio LY
3. modifiche utente proprio profilo, dati utente deve essere eliminata e rileggere su richiesta successiva dal DB

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

Ciò che non voglio è anche scrivere/leggere alcune variabili/chiavi codificate e manipolarle in altre parti dell'applicazione. Questo presenterebbe solo il debito tecnico.

Domande

1. Cosa suggeriresti?
2. In che modo SO persistono i dati 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 il modo in cui gli utenti accedono, avvolgere la cache in un oggetto "UserCache".L'oggetto potrebbe essere costruito da un HttpModule e memorizzato come un singleton (ad aspettarlo ...) all'interno della cache stessa o, meglio ancora, appena costruito quando necessario per estrarre dalla cache http. Ciò dipende da dove è necessario accedervi e se HttpContext.Current.Cache è direttamente disponibile. L'implementazione pigra è sotto.

Ancora, questo è per chiarezza e non è come lo implementerei effettivamente.

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 in modo che dipenda anche dagli aggiornamenti del server SQL per gestire gli aggiornamenti o aggiornarla manualmente come parte del servizio per salvare le modifiche.

Ulteriori informazioni sulla cache predefinita sono disponibili here. Ulteriori informazioni su cache dependencies sono disponibili here.

Nello HttpModule stesso, suppongo che si possa fare un po 'di magia nell'evento EndRequest per vedere se la richiesta è autenticata e quindi registrare l'utente in base al cookie, ma non sono sicuro se ciò funzionerebbe come non l'ho mai provato Potresti dare un'occhiata a this article su MSDN da WAY nei giorni 1.1 e vedere se risponde ad alcuni dei problemi che stai cercando di risolvere.

Per quanto riguarda l'architettura SO e il modo in cui lo fanno, immagino che lo caricino quando necessario perché mantengono la maggior parte del database nella RAM in ogni momento (http://highscalability.com/stack-overflow-architecture).