Pola statyczne a zmienne sesji

Do tej pory używałem sesji do przekazywania niektórych zmiennych z jednej strony na drugą. Na przykład rola użytkownika. Gdy użytkownik loguje się do aplikacji webowej, identyfikator roli użytkownika jest przechowywany w sesji i ta rola jest sprawdzana w różnych częściach aplikacji. Ostatnio zacząłem myśleć, dlaczego nie używać static members zamiast. Mogę przechowywać te same informacje w polu statycznym i łatwo uzyskać do nich dostęp w dowolnym miejscu w mojej aplikacji (w dowolnym miejscu przestrzeń nazw, w której znajduje się to pole statyczne wliczony w cenę.) Wiem, że używanie zmiennych sesji czasem się przydaje, np.:

  1. każdy rodzaj danych może być przechowywany w sesji. Następnie należy go jednak odlewać.Ale pola statyczne akceptują dane tylko z prawidłowym typem danych.
  2. zmienne sesji wygasną po pewnym czasie, czego w wielu przypadkach potrzebujemy.

Poza powyższym, czy są inne powody, dla których nie powinienem używać statycznych pól do przechowywania danych i mieć je dostępne wszędzie?

Author: Jacek, 2013-02-06
Source

4 answers

Nie, używanie zmiennych statycznych do tego celu jest , a nie Droga do zrobienia:

  • Jeśli Twoja AppDomain zostanie poddana recyklingowi, wszystkie zmienne statyczne zostaną "zresetowane"
  • zmienne statyczne nie skalują się poziomo - jeśli załadujesz-zrównoważysz aplikację, użytkownik, który uderzy na jeden serwer, a inny nie zobaczy przechowywanych danych w zmiennych statycznych na pierwszym serwerze
  • co najważniejsze, zmienne statyczne będą współdzielone przez cały dostęp do tego serwera... nie będzie na w ogóle na użytkownika... natomiast z twojego opisu nie chciałbyś, aby użytkownik X widział informacje użytkownika Y.

Zasadniczo masz dwie możliwości propagowania informacji wokół swojej aplikacji:

  • zachowaj to po stronie klienta, więc każde żądanie podaje informacje z poprzednich kroków. (Może to stać się nieporęczne z dużą ilością informacji, ale może być przydatne w prostych przypadkach.)
  • zachować po stronie serwera, najlepiej w jakiś trwały sposób (np. bazy danych) z podaniem przez Klienta identyfikatora sesji.

Jeśli możesz użyć load-balancing, aby utrzymać wszystkich użytkowników na tym samym serwerze, i Jeśli {[2] } nie przeszkadza ci utrata sesji, gdy AppDomain jest odzyskiwany1 lub serwer się wyłącza, można go zachować w pamięci, keyed przez identyfikator sesji... ale bądź ostrożny.

1 mogą istnieć mechanizmy w ASP.NET aby to przetrwać, propagując informacje o sesji z jednego AppDomain do drugiego-jestem Nie wiem

 35
Author: Jon Skeet,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-02-05 09:22:45

To dwie różne rzeczy.

  • sesja może być używana poza procesem (ważne dla równoważenia obciążenia)
  • sesja może być trwalsza ze względu na brak możliwości procesowych.
  • ASP.Net automatycznie zarządza współbieżnością sesji.
  • Dostęp do zmiennych statycznych wymaga ręcznej synchronizacji.
  • Static jest globalny dla całej domeny aplikacji. Jeśli ustawisz wartość statycznego pola / właściwości dla jednego użytkownika, wszyscy użytkownicy otrzymają to samo wartość. Nie pożądane zachowanie w Twoim scenariuszu.

Każdy rodzaj danych może być przechowywany w sesji. Następnie należy go odlewać jednak.Ale pola statyczne akceptują dane tylko z prawidłowym typem danych.

Często pomocne jest abstrakcyjne wartości sesji z klasą pomocniczą. Może to poprawić testowalność, a także pozwala silnie wpisywać właściwości i wykonywać odlewy we wnętrzach klasy.

Przykład: 

public List<int> UserRoles
{
    get
    {
        // optionally check that the value is indeed in session, otherwise this 
        // will throw
        return (List<int>)Session["UserRoles"];
    }
}

Zobacz:

 12
Author: Tim Medora,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:17:17

Zapominasz o jednej rzeczy (myślę)

Dane statyczne będą takie same dla wszystkich użytkowników aplikacji, podczas gdy sesja będzie "na użytkownika".

Więc za scenariusz "roli użytkownika" spodziewałbym się śmiesznych efektów;)

 9
Author: Raphaël Althaus,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-02-06 07:12:17

Statyczne pola będą współdzielone przez wszystkich użytkowników.
W as web environment będziesz miał kilka wątków działających razem.

Aktualizacja statycznych elementów wymaga odpowiedniej kontroli współbieżności. Źle wykonane, znacznie spowolni to wydajność witryny.

Sesje można przenieść poza proces i udostępnić na farmie internetowej.

Out of proc sessions would exist even if your app server crashed.

 6
Author: nunespascal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-02-06 07:12:54