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.

Scarica 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 a 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 altre 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 parla 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 avanti e indietro un blocco di testo codificato di grandi dimensioni al browser. Il campo ViewState potrebbe essere sopraffatto dal contenuto di una pagina contenente molti elementi, espandendosi potenzialmente fino a raggiungere dimensioni di diversi megabyte.

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 dei componenti è immediatamente disponibile e non viene ricompilato tra le interazioni.
• Lo stato non viene trasmesso al browser.

Tuttavia, la persistenza dello stato dei componenti in memoria presenta alcuni svantaggi di cui tenere conto:

• Se il server viene riavviato tra una richiesta e l'altra, lo stato viene perso.
• La soluzione di bilanciamento del carico del server Web dell'applicazione deve includere delle 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 dei componenti sul server può comportare una pressione sulla memoria del server web.

Per i motivi precedenti, non si deve fare affidamento solo sullo stato del componente che risiede 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. Scrivere i dati tra ogni post dell'utente in un archivio dati in modo che possano essere recuperati e assemblati nella struttura di risposta finale del modulo al termine del modulo in più parti.

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

Mantenere lo stato con Sessione

Gli sviluppatori di Web Form possono mantenere informazioni sull'utente attualmente in funzione con l'oggetto dizionario Microsoft.AspNetCore.Http.ISession. È abbastanza semplice aggiungere un oggetto con una chiave stringa all'oggetto Session, e 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 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 per ASP.NET stato core e 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 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 archiviarli facilmente in un servizio singleton che può essere inserito in componenti che richiedono queste informazioni o interazioni.

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 valore VisitorCounter 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 siano disponibili 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, poi il browser fornisce lo stesso localStorage
• sessionStorage - con ambito alla scheda del browser corrente dell'utente. Se la scheda viene ricaricata, lo stato persiste. 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.

PrecedenteSuccessivo