Gestione dello stato

Suggerimento

Questo contenuto è un estratto dell'eBook Blazor for ASP NET Web Form Developers for Azure, disponibile in .NET Docs o come PDF scaricabile gratuito che può essere letto offline.

Scaricare il PDF

La gestione dello stato è un concetto chiave di applicazioni Web Form, facilitato tramite le funzionalità ViewState, Stato sessione, Stato applicazione e Postback. Queste funzionalità con stato del framework hanno contribuito a nascondere la gestione dello stato necessaria per un'applicazione e consentire agli sviluppatori di applicazioni di concentrarsi sulla distribuzione delle funzionalità. Con ASP.NET Core e Blazor, alcune di queste funzionalità sono state rilocate e alcune sono state rimosse completamente. Questo capitolo esamina come mantenere lo stato e offrire le stesse funzionalità con le nuove funzionalità in Blazor.

Gestione dello stato della richiesta con ViewState

Quando si discute di gestione dello stato nell'applicazione Web Form, molti sviluppatori penseranno immediatamente a ViewState. In Web Form ViewState gestisce lo stato del contenuto tra le richieste HTTP inviando un blocco di testo codificato di grandi dimensioni avanti e indietro al browser. Il campo ViewState potrebbe essere sovraccaricato con il contenuto di una pagina contenente molti elementi, potenzialmente espandendo fino a diversi megabyte di dimensioni.

Con Blazor Server, l'app mantiene una connessione continua con il server. Lo stato dell'app, denominato circuito, viene mantenuto nella memoria del server mentre la connessione è considerata attiva. Lo stato verrà eliminato solo quando l'utente si allontana dall'app o da una determinata pagina nell'app. Tutti i membri dei componenti attivi sono disponibili tra le interazioni con il server.

Questa funzionalità offre diversi vantaggi:

• Lo stato del componente è facilmente accessibile e non viene rigenerato tra le interazioni.
• Lo stato non viene trasmesso al browser.

Esistono tuttavia alcuni svantaggi per la persistenza dello stato del componente in memoria per tenere presente quanto indicato di seguito:

• Se il server viene riavviato tra una richiesta e l'altro, lo stato viene perso.
• La soluzione di bilanciamento del carico del server Web dell'applicazione deve includere sessioni permanenti per garantire che tutte le richieste dello stesso browser tornino allo stesso server. Se una richiesta passa a un server diverso, lo stato andrà perso.
• La persistenza dello stato del componente nel server può causare una pressione di memoria sul server Web.

Per i motivi precedenti, non fare affidamento solo sullo stato del componente per mantenere i dati in memoria sul server. L'applicazione deve includere anche un archivio dati di backup per i dati tra le richieste. Alcuni semplici esempi di questa strategia:

• In un'applicazione carrello acquisti rendere persistente il contenuto dei nuovi elementi aggiunti al carrello in un record di database. Se lo stato del server viene perso, è possibile ricostituirlo dai record del database.
• In un modulo Web in più parti, gli utenti si aspettano che l'applicazione ricordi i valori tra ogni richiesta. Scrivi i dati tra ogni post dei tuoi utenti in un archivio dati in modo che possano essere recuperati e assemblati quando viene completato il modulo a più parti.

Per altri dettagli sulla gestione dello stato nelle app Blazor, vedere ASP.NET Gestione dello stato di Core Blazor.

Mantenere lo stato con sessione

Gli sviluppatori di Web Forms possono mantenere informazioni sull'utente attualmente attivo con l'oggetto dizionario Microsoft.AspNetCore.Http.ISession. È abbastanza semplice aggiungere un oggetto con una chiave stringa all'oggetto Sessione tale oggetto sarà disponibile in un secondo momento durante le interazioni dell'utente con l'applicazione. Nel tentativo di eliminare la gestione dell'interazione con HTTP, l'oggetto Session ha reso più semplice mantenere lo stato.

La firma dell'oggetto .NET Framework Session non corrisponde all'oggetto ASP.NET Core Session . Prendere in considerazione la documentazione per la nuova sessione principale di ASP.NET prima di decidere di eseguire la migrazione e usare la nuova funzionalità di stato della sessione.

La sessione è disponibile in ASP.NET Core e Blazor Server, ma è sconsigliata l'uso a favore dell'archiviazione dei dati in un repository di dati in modo appropriato. Lo stato della sessione non è funzionale anche se i visitatori rifiutano l'uso dei cookie HTTP nell'applicazione a causa di problemi di privacy.

La configurazione di ASP.NET Core e stato di sessione è disponibile nell'articolo Sessione e gestione dello stato in ASP.NET Core.

Stato dell'applicazione

L'oggetto Application nel framework Web Form offre un repository di richieste incrociate di grandi dimensioni per interagire con la configurazione e lo stato dell'ambito dell'applicazione. Lo stato dell'applicazione è una posizione ideale per archiviare varie proprietà di configurazione dell'applicazione a cui si fa riferimento da tutte le richieste, indipendentemente dall'utente che effettua la richiesta. Il problema relativo all'oggetto Application era che i dati non venivano mantenuti in più server. Lo stato dell'oggetto dell'applicazione è stato perso tra i riavvii.

Come per Session, è consigliabile spostare i dati in un archivio di backup permanente a cui è possibile accedere da più istanze del server. Se sono presenti dati volatili a cui si vuole poter accedere tra richieste e utenti, è possibile archiviarlo facilmente in un servizio singleton che può essere inserito in componenti che richiedono queste informazioni o interazione.

La costruzione di un oggetto per mantenere lo stato dell'applicazione e il relativo consumo potrebbe essere simile all'implementazione seguente:

public class MyApplicationState
{
    public int VisitorCounter { get; private set; } = 0;

    public void IncrementCounter() => VisitorCounter += 1;
}

app.AddSingleton<MyApplicationState>();

@inject MyApplicationState AppState

<label>Total Visitors: @AppState.VisitorCounter</label>

L'oggetto MyApplicationState viene creato una sola volta nel server e il valore VisitorCounter viene recuperato e restituito nell'etichetta del componente. Il VisitorCounter valore deve essere salvato in modo permanente e recuperato da un archivio dati di backup per durabilità e scalabilità.

Nel browser

I dati dell'applicazione possono anche essere archiviati sul lato client nel dispositivo dell'utente in modo che sia disponibile in un secondo momento. Esistono due funzionalità del browser che consentono la persistenza dei dati in ambiti diversi del browser dell'utente:

• localStorage - con ambito per l'intero browser dell'utente. Se la pagina viene ricaricata, il browser viene chiuso e riaperto oppure viene aperta un'altra scheda con lo stesso URL, lo stesso localStorage viene fornito dal browser
• sessionStorage - limitato alla scheda del browser corrente dell'utente. Se la scheda viene aggiornata, lo stato rimane. Tuttavia, se l'utente apre un'altra scheda all'applicazione o chiude e riapre il browser lo stato viene perso.

È possibile scrivere codice JavaScript personalizzato per interagire con queste funzionalità oppure sono disponibili numerosi pacchetti NuGet che è possibile usare per fornire questa funzionalità. Un pacchetto di questo tipo è Microsoft.AspNetCore.ProtectedBrowserStorage.

Per istruzioni sull'uso di questo pacchetto per interagire con localStorage e sessionStorage, vedere l'articolo Blazor State Management .

PrecedenteAvanti