Gerenciamento de estado

O gerenciamento de estado é um conceito fundamental de aplicativos Web Forms, facilitado por meio dos recursos ViewState, Session State, Application State e Postback. Esses recursos com estado da estrutura ajudaram a ocultar o gerenciamento de estado necessário para um aplicativo e permitir que os desenvolvedores de aplicativos se concentrassem em fornecer suas funcionalidades. Com o ASP.NET Core e o Blazor, alguns desses recursos foram realocados e outros foram removidos completamente. Este capítulo analisa como manter o estado e entregar a mesma funcionalidade com os novos recursos no Blazor.

Solicitar o gerenciamento de estado com ViewState

Ao discutir o gerenciamento de estado no aplicativo Web Forms, muitos desenvolvedores pensarão imediatamente no ViewState. No Web Forms, o ViewState gerencia o estado do conteúdo entre solicitações HTTP enviando um grande bloco codificado de texto para o navegador. O campo ViewState pode ser sobrecarregado com o conteúdo de uma página que contém muitos elementos, potencialmente expandindo para vários megabytes de tamanho.

Com o Blazor Server, o aplicativo mantém uma conexão contínua com o servidor. O estado do aplicativo, chamado de circuito, é mantido na memória do servidor enquanto a conexão é considerada ativa. O estado só será descartado quando o usuário navegar para longe do aplicativo ou de uma página específica no aplicativo. Todos os membros dos componentes ativos estão disponíveis entre interações com o servidor.

Esse recurso tem várias vantagens:

• O estado do componente está prontamente disponível e não é recriado entre interações.
• O estado não é transmitido para o navegador.

No entanto, esteja ciente que há algumas desvantagens com relação à persistência do estado do componente na memória:

• Se o servidor for reiniciado entre a solicitação, o estado será perdido.
• Sua solução de balanceamento de carga do servidor Web do aplicativo deve incluir sessões autoadesivas para garantir que todas as solicitações do mesmo navegador retornem ao mesmo servidor. Se uma solicitação for para um servidor diferente, o estado será perdido.
• A persistência do estado do componente no servidor pode levar à pressão de memória no servidor Web.

Pelos motivos anteriores, não dependa apenas do estado do componente para residir na memória no servidor. Seu aplicativo também deve incluir alguns armazenamentos de dados de backup para dados entre solicitações. Alguns exemplos simples dessa estratégia:

• Em um aplicativo de carrinho de compras, persista o conteúdo de novos itens adicionados ao carrinho em um registro de banco de dados. Se o estado no servidor for perdido, você poderá reconstituí-lo a partir dos registros de banco de dados.
• Em um formulário Web de várias partes, os usuários esperam que seu aplicativo lembre-se dos valores entre cada solicitação. Grave os dados entre cada uma das postagens do usuário em um armazenamento de dados para que eles possam ser buscados e montados na estrutura de resposta do formulário final, quando o formulário de várias partes for concluído.

Para obter mais detalhes sobre como gerenciar o estado em aplicativos do Blazor, confira Gerenciamento de estado do Blazor no ASP.NET Core.

Manter o estado com a sessão

Os desenvolvedores de Web Forms poderiam manter informações sobre o usuário que está agindo atualmente com o objeto de dicionário Microsoft.AspNetCore.Http.ISession. É fácil adicionar um objeto com uma chave de cadeia de caracteres a Session, esse objeto ficaria disponível posteriormente durante as interações do usuário com o aplicativo. Na tentativa de eliminar o gerenciamento da interação com HTTP, o objeto Session facilitou a manutenção do estado.

A assinatura do objeto Session de .NET Framework não é igual ao objeto Session de ASP.NET Core. Considere a documentação da nova sessão de ASP.NET Core antes de decidir migrar e usar o novo recurso de estado de sessão.

A sessão está disponível no ASP.NET Core e no Blazor Server, mas não incentivamos seu uso, preferindo o armazenamento adequado de dados em um repositório de dados. O estado da sessão também não estará funcional se os visitantes recusarem o uso de cookies HTTP em seu aplicativo devido a preocupações de privacidade.

A configuração para ASP.NET Core e o estado de sessão está disponível no artigo Gerenciamento de sessão e de estado no ASP.NET Core.

Estado do aplicativo

O objeto Application na estrutura Web Forms fornece um repositório de solicitação cruzada enorme para interagir com a configuração e o estado do escopo do aplicativo. O estado do aplicativo era um local ideal para armazenar várias propriedades de configuração de aplicativo que seriam referenciadas por todas as solicitações, independentemente de o usuário fazer a solicitação. O problema com o objeto Application era que os dados não persistiam em vários servidores. O estado do objeto de aplicativo foi perdido entre reinicializações.

Assim como acontece com Session, recomendamos que os dados se movam para um repositório de backup persistente que poderia ser acessado por várias instâncias de servidor. Se houver dados voláteis que você gostaria de poder acessar entre solicitações e usuários, você poderá armazená-los facilmente em um serviço singleton que pode ser injetado em componentes que exigem essas informações ou interação.

A construção de um objeto para manter o estado do aplicativo e seu consumo pode se assemelhar à seguinte implementação:

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>

O objeto MyApplicationState é criado apenas uma vez no servidor, e o valor VisitorCounter é buscado e gerado no rótulo do componente. O valor VisitorCounter deve ser persistido e recuperado de um repositório de dados de backup para durabilidade e escalabilidade.

No navegador

Os dados do aplicativo também podem ser armazenados no lado do cliente no dispositivo do usuário para que fiquem disponíveis posteriormente. Há dois recursos do navegador que permitem a persistência de dados em escopos diferentes do navegador do usuário:

• localStorage – com escopo para todo o navegador do usuário. Se a página for recarregada, o navegador será fechado e reaberto, ou outra guia será aberta com a mesma URL, então o mesmo localStorage será fornecido pelo navegador
• sessionStorage – com escopo para a guia atual do navegador do usuário. Se a guia for recarregada, o estado persistirá. No entanto, se o usuário abrir outra guia para seu aplicativo ou fechar e reabrir o navegador, o estado será perdido.

Você pode escrever algum código JavaScript personalizado para interagir com esses recursos, ou há vários pacotes NuGet que podem ser usados para fornecer essa funcionalidade. Um desses pacotes é Microsoft.AspNetCore.ProtectedBrowserStorage.

Para obter instruções sobre como utilizar esse pacote para interagir com localStorage e sessionStorage, confira o artigo Gerenciamento de estado do Blazor.