Persistierende / Caching von Daten zwischen den Anfragen - gemeinsames Konzept

Question

Ich entwickle eine Asp.net (MVC aber das ist nicht wirklich wichtig) Anwendung. Ich habe eine benutzerdefinierte IHttpModule das ist verantwortlich für die PostAuthenticateRequest Benutzerprinzipal zu ändern und Identität.

Ich bin Speicherung UserID und Benutzername in Authentifizierungs-Cookie, wenn der Benutzer meldet sich. Ich habe eine IUser (implementiert durch DAO und Business Objects-Schicht, jede mit ihren eigenen zusätzlichen Mitgliedern), die ich alle über Business Service-Klassen benötigen. Wenn ein Benutzer etwas will ich IUser Objektinstanz zur Verfügung zu stellen (in der Regel von der Business-Schicht-Objekten) ID aus dem Auth-Ticket so bot nicht ausreichend ist.

Also ich denke an, wie und wo wäre am besten in IUser Daten des angemeldeten Benutzers beharren?

1. Ich mag nicht jedes Mal von der DB holen (basierend auf dem Authentifizierungsticket UserID Daten)
2. Ich kann es in der Sitzung nicht speichern, da ich in PostAuthenticateRequest arbeiten muß, wo Session noch nicht bereit ist,
3. Ich möchte alle Funktionen innerhalb meiner benutzerdefinierten IHttpModule
verkapselt werden

Auswahl, die ich sehe:

• Cache
• Cookie
• (Session) - durch von PostAuthenticateRequest zu PostAcquireRequestState Ereignis zu bewegen und ändern Haupt / Identität gibt, aber ich möchte diese
vermeiden

Prozesse, die Dinge zu verkomplizieren scheinen, sind:

1. Benutzer meldet sich, ist Benutzerdaten abgerufen aus der DB und blieb irgendwie für spätere Anfragen
2. Benutzerprotokolle-out hat Benutzerdaten von persistenten Medium entfernt werden automagically
3. Benutzer Änderungen eigenes Profil hat Nutzdaten verworfen und auf nächste Anfrage aus der DB
nachgelesen werden

I wan't diese alle von Httpmodule automatisch gehandhabt werden (wenn möglich) Entwickler-Fehler des Vergessens zu beseitigen, diese Dinge zu setzen.

Was ich nicht auch wollen, ist einige hartcodierte Variablen / Tasten und manipulieren sie in anderen Teilen der Anwendung schreiben / lesen. Dies würde nur die technische Schulden vor.

Fragen

1. Was würden Sie vorschlagen?
2. Wie anhalten SO Benutzerdaten zwischen den Anfragen?

Answer 1

Ihre Anforderungen gegeben, nehme ich die beste Lösung, um die ID aus dem Cookie abzurufen ist und es Index in den HTTP-Cache zu verwenden (HttpContext.Current.Cache).

Wenn Sie pflegen wollen, wie die Benutzer darauf zugreifen, wickeln Sie den Cache in einem „UserCache“ Objekt. Das Objekt konnte von einem Httpmodule und gespeichert als konstruiert wird (warten, bis es ...) Singleton im Cache selbst oder, noch besser, nur gebaut, wenn sie von der HTTP-Cache zu ziehen braucht. Dies würde davon abhängen, wo Sie darauf zugreifen müssen und ob HttpContext.Current.Cache ist direkt verfügbar. Die faule Implementierung ist unten.

Auch dies ist aus Gründen der Klarheit und nicht ist, wie ich es tatsächlich umsetzen würde.

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

Unter Verwendung der Standard-Caching-Mechanismen (oder besser noch einen Caching-Mechanismus von DI geliefert, so dass Sie auf eine Implementierung nicht gebunden sind), können Sie einen Ablauf auf Benutzer automatisch aus dem Cache zu entfernen, wie im Kommentar erwähnt. Sie können Setup die Cache auf SQL Server-Updates und abhängig zu sein, das Updates zu handhaben oder manuell als Teil des Dienstes aktualisieren, um Änderungen zu speichern.

Weitere Informationen über die Standard-Cache verfügbar hier . Weitere Informationen über Cache Abhängigkeiten ist verfügbar < a href = "http://msdn.microsoft.com/en-us/library/system.web.caching.cachedependency.aspx" rel = "nofollow noreferrer"> hier .

In der Httpmodule selbst, ich nehme an, Sie könnten etwas Magie in dem Endrequest-Ereignisse tun, um zu sehen, ob die Anforderung authentifiziert wird, und dann den Benutzer aus auf dem Cookies in Ihrem Browser einzuloggen, aber ich bin nicht sicher, ob das funktionieren würde, wie ich habe es nie versucht. Vielleicht haben Sie einen Blick auf diesem Artikel auf MSDN haben wollen in den 1,1 Tage von Weg zurück und sehen, ob es einige der Probleme Antworten Sie versuchen zu lösen.

Wie für die SO-Architektur und wie sie es tun, ich kann mir vorstellen, sie es bei Bedarf laden, weil sie zu jeder Zeit die meisten der Datenbank im RAM halten ( http://highscalability.com/stack-overflow-architecture ).