Trwałe/buforowanie danych między żądaniami - wspólne podejście

Question

Zajmuję się tworzeniem aplikacji Asp.net (MVC, ale to nie ma znaczenia). Mam niestandardowy moduł IHttpModule, który odpowiada za PostAuthenticateRequest, aby zmienić tożsamość użytkownika głównego &.

Przechowuję identyfikator użytkownika i nazwę użytkownika w pliku cookie uwierzytelniania, gdy użytkownik się loguje. Mam IUser (zaimplementowany przez warstwę DAO i Business Objects, każdy z własnym dodatkowym członkiem), którego potrzebuję na wszystkich klasach Business Service. Gdy użytkownik czegoś chce, muszę dostarczyć instancję obiektu IUser (zwykle z warstwy Business Objects), więc podanie identyfikatora z biletu auth nie jest wystarczające.

Zastanawiam się więc, w jaki sposób i gdzie najlepiej byłoby przechowywać dane zalogowanego użytkownika IUser?

1. Nie chcę, aby pobrać go za każdym razem z DB (na podstawie danych identyfikatora użytkownika Uwierzytelnianie za bilet)
2. Nie mogę przechowywać go w sesji, ponieważ mam do pracy wewnątrz PostAuthenticateRequest, gdzie ISN Session” t gotowy jeszcze
3. Chcę wszystkie funkcje mają być zamknięte w moim zwyczaju IHttpModule

wyborów, które widzę:

• Cache
• Cookie
• (Session) - przesuwając z PostAuthenticateRequest do wydarzenia PostAcquireRequestState i zmienić główny/tożsamości tam, ale chciałbym, aby tego uniknąć

procesów, które wydają się komplikować to:

1. logi-in użytkownika, dane użytkownika są pobierane z DB i utrzymywały się jakoś na później żąda
2. użytkownik loguje-out, dane użytkownika, musi zostać usunięty z utrzymywały się średnio automagical ly
3. Zmiany Użytkownika własny profil, dane użytkownika musi być odrzucone i ponownie przeczytać na następne żądanie od DB

ja wa nie wszystko, aby być obsługiwane automatycznie przez HttpModule (jeśli to możliwe), aby wyeliminować błędy dewelopera z zapominając zresetować te rzeczy.

Czego również nie chcę, jest zapisanie/odczytanie niektórych zakodowanych zmiennych/kluczy i manipulowanie nimi w innych częściach aplikacji. To byłby tylko dług techniczny.

Pytania

1. Co proponujesz?
2. W jaki sposób SO zachowuje dane użytkownika między żądaniami?

Answer 1

Biorąc pod uwagę twoje wymagania, przypuszczam, że najlepszym rozwiązaniem jest pobranie identyfikatora z pliku cookie i użycie go do indeksowania w pamięci podręcznej Http (HttpContext.Current.Cache).

Jeśli chcesz zachować sposób, w jaki użytkownicy uzyskują do niego dostęp, zawiń pamięć podręczną w obiekcie "UserCache".Obiekt mógłby zostać skonstruowany przez moduł HttpModule i przechowywany jako singleton (czekający na niego) w samej pamięci podręcznej lub, jeszcze lepiej, skonstruowany, gdy jest potrzebny do pobrania z pamięci podręcznej http. Zależy to od tego, gdzie trzeba uzyskać do niego dostęp i czy HttpContext.Current.Cache jest bezpośrednio dostępny. Leniwa implementacja znajduje się poniżej.

Ponownie, jest to dla jasności i nie jest tak, jakbym to zaimplementował.

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

Korzystanie z mechanizmów buforowania domyślny (lub jeszcze lepiej mechanizm buforowania dostarczane przez DI więc nie jesteś przywiązany do realizacji), można ustawić upływie automatycznie usunąć użytkowników z pamięci podręcznej, jak wspomniano w komentarzu . Możesz ustawić pamięć podręczną jako zależną od aktualizacji serwera SQL, a także obsłużyć aktualizacje lub ręcznie zaktualizować je jako część usługi, aby zapisać zmiany.

Więcej informacji o domyślnej pamięci podręcznej jest dostępnych here. Więcej informacji o cache dependencies jest dostępnych here.

W samym HttpModule, przypuszczam, że można zrobić trochę magii w zdarzeniu EndRequest, aby sprawdzić, czy żądanie jest uwierzytelnione, a następnie zalogować użytkownika na podstawie cookie, ale nie jestem pewien, czy to działałoby jak ja Nigdy tego nie próbowałem. Możesz chcieć rzucić okiem na this article na MSDN z WAY w ciągu 1.1 dni i sprawdzić, czy odpowiada on niektórym problemom, które próbujesz rozwiązać.

Jeśli chodzi o architekturę SO i sposób, w jaki to robią, wyobrażam sobie, że ładują ją w razie potrzeby, ponieważ przechowują większość danych w pamięci RAM przez cały czas (http://highscalability.com/stack-overflow-architecture).