Gerenciamento de estado

Dica

Esse conteúdo é um trecho do eBook, Blazor para Desenvolvedores do ASP NET Web Forms para Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

O gerenciamento de estado é um conceito fundamental de aplicativos Web Forms, facilitado por meio de recursos ViewState, Estado da Sessão, Estado do Aplicativo 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 concentrem na implementação de suas funcionalidades. Com ASP.NET Core e Blazor, alguns desses recursos foram realocados e alguns foram removidos completamente. Este capítulo analisa como manter o estado e fornecer a mesma funcionalidade com os novos recursos no Blazor.

Solicitar gerenciamento de estado com ViewState

Ao discutir o gerenciamento de estado no aplicativo Web Forms, muitos desenvolvedores pensarão imediatamente em ViewState. Nos Web Forms, o ViewState gerencia o estado do conteúdo entre solicitações HTTP enviando um grande bloco de texto codificado de volta e para frente 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, denominado circuito, é mantido na memória do servidor enquanto a conexão estiver 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.

Há várias vantagens desse recurso:

• 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, é importante estar ciente de algumas desvantagens na persistência do estado do componente em memória.

• Se o servidor for reiniciado entre a solicitação, o estado será perdido.
• A solução de balanceamento de carga do servidor do aplicativo web deve incluir sessões persistentes 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.

Por esses motivos, não confie apenas no estado do componente para permanecer na memória no servidor. Seu aplicativo também deve incluir algum repositório 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 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 detalhes adicionais sobre como gerenciar o estado em aplicativos Blazor, consulte ASP.NET gerenciamento de estado do Core Blazor.

Manter o estado com a sessão

Os desenvolvedores do Web Forms podem manter informações sobre o usuário que está atuando no momento com o Microsoft.AspNetCore.Http.ISession objeto de dicionário. É bastante fácil adicionar um objeto com uma chave de string ao Session, e esse objeto estará 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 Session objeto facilitou a manutenção do estado.

A assinatura do objeto .NET Framework Session não é a mesma do objeto ASP.NET Core Session . Considere a documentação da nova sessão do 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 questões de privacidade.

A configuração para ASP.NET Core e 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 o local ideal para armazenar várias propriedades de configuração de aplicativo que seriam referenciadas por todas as solicitações, independentemente do usuário que fez a solicitação. O problema com o objeto Application era que os dados não persistiam entre vários servidores. O estado do objeto de aplicativo foi perdido entre as reinicializações.

Assim como acontece Session, é recomendável que os dados sejam movidos para um repositório de backup persistente que possa 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 ser semelhante à 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 MyApplicationState objeto é criado apenas uma vez no servidor e o valor VisitorCounter é buscado e gerado no rótulo do componente. O VisitorCounter valor 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 estejam disponíveis posteriormente. Há dois recursos do navegador que permitem a persistência de dados em escopos diferentes do navegador do usuário:

• localStorage – abrange 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 do seu aplicativo ou fechar o navegador e reabri-lo, o estado será perdido.

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

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

AnteriorPróximo