Persistance / données de mise en cache entre les demandes - approche commune

Question

Je développe une application Asp.net MVC (mais cela ne compte pas vraiment). J'ai une coutume IHttpModule qui est responsable de la PostAuthenticateRequest changer principale et identité utilisateur.

Je suis le stockage et UserID dans UserName cookie d'authentification lorsque l'utilisateur connecte-in. J'ai un IUser (mis en œuvre par DAO et Business Objects couche, chacun avec leurs propres membres supplémentaires) que j'ai besoin partout dans les classes de services d'affaires. Lorsqu'un utilisateur veut tout ce que je dois fournir instance d'objet IUser (habituellement de la couche Business Objects) fournissant ainsi ID du billet d'auth ne suffit pas.

Alors, je pense à comment et où serait le mieux Persister connecté les données IUSER de l'utilisateur?

1. Je ne veux pas chercher à chaque fois de la DB (basée sur les données de UserID ticket d'authentification)
2. Je ne peux pas stocker en session depuis que je dois travailler à l'intérieur PostAuthenticateRequest, où la session est pas encore prêt
3. Je veux toutes les fonctionnalités à encapsuler dans mon coutume IHttpModule

Choix que je vois:

• Cache
• Cookie
• (Session) - en passant de PostAuthenticateRequest à l'événement PostAcquireRequestState et principal / identité de changement, mais je voudrais éviter ce

Les processus qui semblent compliquer les choses sont:

1. journaux dans l'utilisateur, les données utilisateur sont extraites de la base de données et a persisté en quelque sorte pour les demandes ultérieures
2. l'utilisateur se déconnecte, les données de l'utilisateur doit être retiré de moyen automagiquement persistant
3. Modifications de l'utilisateur propre profil, les données de l'utilisateur doit être mis au rebut et relisez sur demande à côté de la DB

Je wan't tous ces à traiter automatiquement par HttpModule (si possible) pour éliminer les erreurs de développeur d'oublier de remettre ces choses.

Ce que je ne veux pas aussi est d'écrire / lire certaines variables clés et / hardcoded les manipuler dans d'autres parties de l'application. Cela ne ferait que présenter la dette technique.

Questions

1. Que proposeriez-vous?
2. Comment ne persiste SO données utilisateur entre les demandes?

Answer 1

Compte tenu de vos besoins, je suppose que la meilleure solution est de récupérer l'ID du cookie et l'utiliser pour indexer dans le cache Http (HttpContext.Current.Cache).

Si vous souhaitez conserver comment les utilisateurs accèdent, envelopper le cache dans un objet « UserCache ». L'objet pourrait être construit par un HttpModule et stocké en tant que (attendez qu'il ...) singleton dans le cache lui-même ou, mieux encore, juste construit au besoin de tirer à partir du cache http. Cela dépend de l'endroit où vous avez besoin pour y accéder et si HttpContext.Current.Cache est directement disponible. La mise en œuvre est paresseux ci-dessous.

Encore une fois, ceci est pour la clarté et comment je fait l'appliquer.

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

En utilisant les mécanismes de mise en cache par défaut (ou mieux encore un mécanisme de mise en cache fourni par DI de sorte que vous n'êtes pas lié à une mise en œuvre), vous pouvez définir une expiration pour supprimer automatiquement les utilisateurs du cache comme mentionné dans le commentaire. Vous pouvez configurer le cache à dépendre des mises à jour du serveur SQL et pour gérer les mises à jour ou mettre à jour manuellement dans le cadre du service pour enregistrer les modifications.

Plus d'informations sur le cache par défaut est disponible ici . Plus d'informations sur cache des dépendances est disponible < a href = "http://msdn.microsoft.com/en-us/library/system.web.caching.cachedependency.aspx" rel = "nofollow noreferrer"> ici .

Dans le HttpModule lui-même, je suppose que vous pourriez faire de la magie en cas EndRequest pour voir si la demande est authentifiée et puis connectez-vous à l'utilisateur en se basant sur le cookie, mais je ne suis pas sûr si cela fonctionne comme je l » ai jamais essayé. Vous pouvez jeter un oeil à cet article sur MSDN de retour dans les WAY 1.1 jours et voir si elle répond à certains des problèmes que vous essayez de résoudre.

En ce qui concerne l'architecture SO et comment ils le font, je suppose qu'ils le charger en cas de besoin parce qu'ils gardent la plupart de la base de données dans la RAM en tout temps ( http://highscalability.com/stack-overflow-architecture ).