zarządzanie stanem po stronie serwera ASP.NET Core Blazor

Trwałość stanu obwodu

Podczas renderowania Blazor Web Apppo stronie serwera można utrwalać stan sesji (obwodu) użytkownika, gdy połączenie z serwerem zostanie utracone przez dłuższy czas lub proaktywnie wstrzymane, o ile odświeżanie pełnostronicowe nie zostanie wyzwolone. Dzięki temu użytkownicy mogą wznowić swoją sesję bez utraty niezapisanej pracy w następujących scenariuszach:

• Ograniczanie zasobów kart przeglądarki
• Użytkownicy urządzeń przenośnych przełączający aplikacje
• Przerwy w działaniu sieci
• Proaktywne zarządzanie zasobami (wstrzymywanie nieaktywnych obwodów)
• Ulepszona nawigacja

Zasoby serwera można zwolnić, jeśli stan obwodu można utrwalić, a następnie wznowić później:

• Nawet w przypadku rozłączenia obwód może nadal wykonywać pracę i zużywać procesor CPU, pamięć i inne zasoby. Stan trwały zużywa tylko stałą ilość pamięci, którą kontroluje deweloper.
• Stan zapisany reprezentuje podzbiór pamięci zajmowanej przez aplikację, więc serwer nie musi śledzić składników aplikacji ani innych obiektów po stronie serwera.

Stan jest utrwalany w dwóch scenariuszach:

• Stan składnika: stan składników używanych do renderowania serwera interakcyjnego, na przykład lista elementów pobranych z bazy danych lub formularza wypełnianego przez użytkownika.
• Usługi o określonym zakresie: stan przechowywany w usłudze po stronie serwera, na przykład bieżący użytkownik.

Warunki:

• Ta funkcja jest skuteczna tylko w przypadku renderowania na serwerze interaktywnym.
• Jeśli użytkownik odświeży stronę (aplikację), stan utrwalonego zostanie utracony.
• Stan musi być serializowalny w formacie JSON. Odwołania cykliczne lub encje ORM mogą nie serializować się poprawnie.
• Użyj @key dla unikalności podczas renderowania elementów w pętli, aby uniknąć konfliktu kluczy.
• Utrwalaj tylko stan niezbędny. Przechowywanie nadmiernych danych może mieć wpływ na wydajność.
• Brak automatycznej hibernacji. Musisz jawnie wyrazić zgodę i skonfigurować trwałość stanu.
• Brak gwarancji odzyskiwania. Jeśli trwałość stanu zakończy się niepowodzeniem, aplikacja powróci do domyślnego trybu rozłączenia.

Trwałość stanu jest domyślnie włączona, gdy AddInteractiveServerComponents jest wywoływana AddRazorComponents w Program pliku. MemoryCache to domyślna implementacja magazynu dla wystąpień pojedynczej aplikacji i przechowuje do 1000 utrwalonych sesji przez dwie godziny, które można skonfigurować według potrzeb.

Użyj następujących opcji, aby zmienić wartości domyślne dostawcy danych w pamięci.

• PersistedCircuitInMemoryMaxRetained ({CIRCUIT COUNT} symbol zastępczy): maksymalna liczba obwodów do zachowania. Wartość domyślna to 1000 obwodów. Na przykład użyj 2000 do utrzymania stanu dla maksymalnie 2000 obwodów.
• PersistedCircuitInMemoryRetentionPeriod ({RETENTION PERIOD} symbol zastępczy): maksymalny okres przechowywania jako TimeSpan. Wartość domyślna to dwie godziny. Na przykład, użyj TimeSpan.FromHours(3) dla okresu przechowywania trzygodzinnego.

services.Configure<CircuitOptions>(options =>
{
    options.PersistedCircuitInMemoryMaxRetained = {CIRCUIT COUNT};
    options.PersistedCircuitInMemoryRetentionPeriod = {RETENTION PERIOD};
});

Zapisywanie stanu składnika między obwodami jest oparte na istniejącym interfejsie API PersistentComponentState, który nadal utrzymuje stan dla wstępnie renderowanych składników, które działają w interaktywnym trybie renderowania. Aby uzyskać więcej informacji, zobacz ASP.NET Core prerendered state persistence (Trwałość stanu wstępnego) ASP.NET CoreBlazor.

[UWAGA] Utrwalanie stanu składnika dla wstępnego przetwarzania działa w przypadku dowolnego trybu renderowania interakcyjnego, ale trwałość stanu obwodu działa tylko w trybie renderowania serwera interaktywnego .

Oznacz właściwości składnika przy użyciu atrybutu[PersistentState], aby umożliwić przechowywanie stanu obwodu. Poniższy przykład również przypisuje klucze do elementów za pomocą atrybutu dyrektywy @key, aby podać unikatowy identyfikator dla każdego wystąpienia składnika.

@foreach (var item in Items)
{
    <ItemDisplay @key="@($"unique-prefix-{item.Id}")" Item="item" />
}

@code {
    [PersistentState]
    public List<Item> Items { get; set; }

    protected override async Task OnInitializedAsync()
    {
        Items ??= await LoadItemsAsync();
    }
}

Aby zachować stan dla usług o określonym zakresie, dodaj adnotację do właściwości usługi za pomocą atrybutu[PersistentState] , dodaj usługę do kolekcji usług i wywołaj RegisterPersistentService metodę rozszerzenia za pomocą usługi:

public class CustomUserService
{
    [PersistentState]
    public string UserData { get; set; }
}

services.AddScoped<CustomUserService>();

services.AddRazorComponents()
  .AddInteractiveServerComponents()
  .RegisterPersistentService<CustomUserService>(RenderMode.InteractiveAuto);

[UWAGA] Powyższy przykład zachowuje UserData stan, gdy usługa jest używana w prerenderowanie komponentów dla renderowania Interactive Server i Interactive WebAssembly, ponieważ RenderMode.InteractiveAuto jest określone do RegisterPersistentService. Jednak trwałość stanu obwodu jest dostępna tylko dla trybu renderowania serwera interaktywnego .

Aby zarządzać trwałością stanu rozproszonego (i działać jako domyślny mechanizm jego trwałości po skonfigurowaniu), przypisz HybridCache (API: HybridCache) do aplikacji, która konfiguruje własny okres przechowywania (PersistedCircuitDistributedRetentionPeriod, domyślnie osiem godzin). HybridCache jest używany, ponieważ zapewnia ujednolicone podejście do magazynu rozproszonego, które nie wymaga oddzielnych pakietów dla każdego dostawcy magazynu.

W poniższym przykładzie HybridCache jest zaimplementowany za pomocą dostawcy pamięci Redis :

services.AddHybridCache()
    .AddRedis("{CONNECTION STRING}");

services.AddRazorComponents()
    .AddInteractiveServerComponents();

W poprzednim przykładzie {CONNECTION STRING} symbol zastępczy reprezentuje parametry połączenia pamięci podręcznej Redis Cache, które powinny być udostępniane przy użyciu bezpiecznego podejścia, takiego jak narzędzie Secret Manager w Development środowisku lub Azure Key Vault z tożsamościami zarządzanymi platformy Azure dla aplikacji wdrożonych na platformie Azure w dowolnym środowisku.

Wstrzymywanie i wznawianie obwodów

Wstrzymywanie i wznawianie obwodów w celu zaimplementowania zasad niestandardowych, które zwiększają skalowalność aplikacji.

Wstrzymując obwód przechowuje szczegółowe informacje o obwodzie w magazynie przeglądarki po stronie klienta i eksmituje obwód, który zwalnia zasoby serwera. Wznawianie obwodu ustanawia nowy obwód i inicjuje go przy użyciu utrwalonego stanu.

Z programu obsługi zdarzeń języka JavaScript:

• Wywołanie Blazor.pause w celu wstrzymania obwodu.
• Wywołanie Blazor.resume w celu wznowienia obwodu.

W poniższym przykładzie przyjęto założenie, że obwód nie jest wymagany dla aplikacji, która nie jest widoczna:

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    Blazor.pause();
  } else if (document.visibilityState === 'visible') {
    Blazor.resume();
  }
});

Utrzymywać stan między obwodami

Ogólnie rzecz biorąc, należy zachować stan między obwodami, w których użytkownicy aktywnie tworzą dane, a nie tylko je odczytują, gdy już istnieją.

Aby zachować stan między obwodami, aplikacja musi utrwalać dane w innym miejscu przechowywania niż pamięć serwera. Trwałość stanu nie jest automatyczna. Należy wykonać kroki podczas tworzenia aplikacji w celu zaimplementowania stanowej trwałości danych.

Trwałość danych jest zwykle wymagana tylko w przypadku stanu o wysokiej wartości, który użytkownicy wydali nakład pracy na utworzenie. W poniższych przykładach utrwalony stan pozwala zaoszczędzić czas lub wspomaga działania komercyjne.

• Formularze wieloetapowe w internecie: Czasochłonne jest dla użytkownika ponowne wprowadzanie danych do kilku ukończonych już kroków wieloetapowego formularza, jeśli ich stan zostanie utracony. Użytkownik utraci stan w tym scenariuszu, jeśli opuści formularz i wróci później.
• Koszyki na zakupy: każdy składnik aplikacji, który reprezentuje potencjalny przychód, może być utrzymywany. Użytkownik, który traci swój stan, a tym samym koszyk zakupów, może zakupić mniej produktów lub usług po powrocie do witryny później.

Aplikacja może utrwalać tylko stan aplikacji. Interfejsy użytkownika nie mogą być zapisywane na stałe, jak na przykład wystąpienia składników i ich drzewa renderowania. Składniki i drzewa renderowania nie są zwykle serializowalne. Aby utrwalyć stan interfejsu użytkownika, taki jak rozwinięte węzły kontrolki widoku drzewa, aplikacja musi używać niestandardowego kodu do modelowania zachowania stanu interfejsu użytkownika jako stanu aplikacji z możliwością serializacji.