statusbeheer aan de serverzijde ASP.NET Core Blazor

Persistentie van circuitstatus

Tijdens het renderen aan de serverzijde kunnen Blazor Web Apps de sessiestatus van een gebruiker (circuit) behouden wanneer de verbinding met de server gedurende een langere periode is verbroken of proactief is onderbroken, mits een volledige paginavernieuwing niet wordt geactiveerd. Hierdoor kunnen gebruikers hun sessie hervatten zonder niet-opgeslagen werk kwijt te raken in de volgende scenario's:

• Regulering van browsertabbladen
• Gebruikers van mobiel apparaat wisselen van apps
• Netwerkonderbrekingen
• Proactief resourcebeheer (onderbreken van inactieve circuits)
• Verbeterde navigatie

Serverresources kunnen worden vrijgemaakt als de circuitstatus kan worden behouden en later kan worden hervat:

• Zelfs als de verbinding is verbroken, kan een circuit blijven werken en CPU, geheugen en andere resources blijven verbruiken. De persistente status verbruikt alleen een vaste hoeveelheid geheugen die door de ontwikkelaar wordt bepaald.
• Persistente status vertegenwoordigt een subset van het geheugen dat door de app wordt gebruikt, zodat de server niet nodig is om de onderdelen van de app en andere objecten aan de serverzijde bij te houden.

Staat wordt behouden voor twee scenario's.

• Onderdeelstatus: staat dat onderdelen worden gebruikt voor het weergeven van interactieve servers, bijvoorbeeld een lijst met items die zijn opgehaald uit de database of een formulier dat de gebruiker invult.
• Scoped services: status binnen een service aan de serverzijde, bijvoorbeeld de huidige gebruiker.

Voorwaarden:

• De functie is alleen effectief voor interactieve serverweergave.
• Als de gebruiker de pagina (app) vernieuwt, gaat de persistente status verloren.
• De status moet JSON serialiseerbaar zijn. Cyclische verwijzingen of ORM-entiteiten worden mogelijk niet correct geserialiseerd.
• Gebruik @key deze functie voor uniekheid bij het weergeven van onderdelen in een lus om belangrijke conflicten te voorkomen.
• Bewaar alleen de noodzakelijke toestand. Het opslaan van overmatige gegevens kan van invloed zijn op de prestaties.
• Geen automatische hibernatiemodus. U moet zich expliciet aanmelden en statuspersistentie configureren.
• Geen garantie voor herstel. Als statuspersistentie mislukt, valt de app terug op de standaard niet-verbonden ervaring.

Staatpersistentie is standaard ingeschakeld wanneer AddInteractiveServerComponents wordt aangeroepen op AddRazorComponents in het Program bestand. MemoryCache is de standaardopslag-implementatie voor exemplaren van één app en slaat maximaal 1000 persistente circuits gedurende twee uur op, die kunnen worden geconfigureerd.

Gebruik de volgende opties om de standaardwaarden van de provider in het geheugen te wijzigen:

• PersistedCircuitInMemoryMaxRetained ({CIRCUIT COUNT} tijdelijke aanduiding): het maximum aantal circuits dat moet worden bewaard. De standaardwaarde is 1000 circuits. Gebruik bijvoorbeeld 2000 om de status voor maximaal 2000 circuits te behouden.
• PersistedCircuitInMemoryRetentionPeriod ({RETENTION PERIOD} plaatsaanduiding): De maximale bewaarperiode is een TimeSpan. De standaardwaarde is twee uur. Gebruik bijvoorbeeld TimeSpan.FromHours(3) voor een bewaarperiode van drie uur.

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

De permanente onderdeelstatus tussen circuits is gebouwd op basis van de bestaande PersistentComponentState API, die de status blijft behouden voor vooraf gegenereerde onderdelen die een interactieve rendermodus gebruiken. Zie ASP.NET Core vooraf samengestelde statuspersistentieBlazor voor meer informatie.

[OPMERKING] Persistente onderdeelstatus voor prerendering werkt voor elke interactieve rendermodus, maar circuitstatuspersistentie werkt alleen voor de weergavemodus interactieve server .

Annoteren van onderdeeleigenschappen met [PersistentState] om de persistentie van de circuitstatus mogelijk te maken. In het volgende voorbeeld worden de items ook voorzien van het @key instructiekenmerk om een unieke identificatie te bieden voor elk onderdeel:

@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();
    }
}

Als u de status voor scoped services wilt behouden, annoteert u service-eigenschappen met [PersistentState], voegt u de service toe aan de serviceverzameling en roept u de extensiemethode RegisterPersistentService aan met de service.

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

services.AddScoped<CustomUserService>();

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

[OPMERKING] In het voorgaande voorbeeld blijft de status van UserData behouden wanneer de service wordt gebruikt bij het prerenderen van componenten voor zowel Interactive Server als Interactive WebAssembly-rendering, doordat RenderMode.InteractiveAuto is opgegeven in RegisterPersistentService. Circuitstatuspersistentie is echter alleen beschikbaar voor de interactieve serverweergavemodus .

Als u gedistribueerde statuspersistentie wilt verwerken (en wilt fungeren als het standaardmechanisme voor statuspersistentie wanneer deze is geconfigureerd), wijst u een HybridCache (API: HybridCache) toe aan de app, die een eigen persistentieperiode configureert (PersistedCircuitDistributedRetentionPeriodstandaard acht uur). HybridCache wordt gebruikt omdat het een uniforme benadering biedt voor gedistribueerde opslag waarvoor geen afzonderlijke pakketten voor elke opslagprovider nodig zijn.

In het volgende voorbeeld wordt een HybridCache geïmplementeerd met de Redis-opslagprovider :

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

services.AddRazorComponents()
    .AddInteractiveServerComponents();

In het voorgaande voorbeeld vertegenwoordigt de {CONNECTION STRING} tijdelijke aanduiding de verbindingsreeks voor de Redis-cache, die moet worden opgegeven met behulp van een veilige benadering, zoals het hulpprogramma Secret Manager in de ontwikkelomgeving of Azure Key Vault met Azure Managed Identities voor door Azure geïmplementeerde apps in elke omgeving.

Circuits onderbreken en hervatten

Pauzeer en hervat circuits om aangepast beleid te implementeren dat de schaalbaarheid van een app verbetert.

Bij het onderbreken van een circuit worden gegevens over het circuit opgeslagen in browseropslag aan de clientzijde en wordt het circuit verwijderd, waardoor serverbronnen worden vrijgemaakt. Als u het circuit hervat, wordt een nieuw circuit tot stand gebracht en geïnitialiseerd met behulp van de persistente status.

Vanuit een JavaScript-gebeurtenis-handler:

• Oproep Blazor.pause om een circuit te onderbreken.
• Bel Blazor.resume om een circuit te hervatten.

In het volgende voorbeeld wordt ervan uitgegaan dat een circuit niet is vereist voor een app die niet zichtbaar is:

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

Status behouden tussen circuits

Over het algemeen houd de status bij over circuits heen waar gebruikers actief gegevens aanmaken en niet slechts gegevens lezen die al bestaan.

Als u de status tussen circuits wilt behouden, moet de app de gegevens bewaren naar een andere opslaglocatie dan het geheugen van de server. Statuspersistentie is niet automatisch. U moet stappen ondernemen bij het ontwikkelen van de app om gegevenspersistentie met behoud van staat te implementeren.

Gegevenspersistentie is doorgaans alleen vereist voor hoogwaardige status die gebruikers moeite hebben gedaan om te creëren. In de volgende voorbeelden bespaart aanhoudende status tijd of helpt in commerciële activiteiten.

• Webformulieren met meerdere stappen: het is tijdrovend voor een gebruiker om gegevens opnieuw in te voeren voor verschillende voltooide stappen van een webformulier met meerdere stappen als de status verloren gaat. Een gebruiker verliest de status in dit scenario als deze weg van het formulier navigeert en later terugkeert.
• Winkelwagens: Elk commercieel belangrijk onderdeel van een app die potentiële omzet vertegenwoordigt, kan worden onderhouden. Een gebruiker die zijn status verliest, en dus zijn winkelwagen, kan minder producten of services kopen wanneer ze later terugkeren naar de site.

Een app kan alleen app-statusbehouden. UI's kunnen niet worden behouden, zoals componenten en hun renderbomen. Onderdelen en renderstructuren zijn over het algemeen niet serialiseerbaar. Om de UI-status te behouden, zoals de uitgebreide knooppunten van een boomstructuurweergave, moet de applicatie aangepaste code gebruiken om het gedrag van de UI-status te modelleren als serialiseerbare applicatiestatus.