Gestão de estados

Gorjeta

Este conteúdo é um excerto do eBook, Blazor for ASP NET Web Forms Developers for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.

Descarregar PDF

O gerenciamento de estado é um conceito-chave de aplicativos Web Forms, facilitado por meio de 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 permitem que os desenvolvedores de aplicativos se concentrem em fornecer 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 do Blazor.

Solicitar gerenciamento de estado com ViewState

Ao discutir o gerenciamento de estado no aplicativo Web Forms, muitos desenvolvedores pensarão imediatamente em ViewState. Em Web Forms, ViewState gerencia o estado do conteúdo entre solicitações HTTP enviando um grande bloco codificado de texto para frente e para trás para o navegador. O campo ViewState pode estar 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á eliminado quando o utilizador navegar para fora da aplicação ou de uma página específica na aplicação. Todos os membros dos componentes ativos estão disponíveis entre as interações com o servidor.

Existem várias vantagens desta funcionalidade:

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

No entanto, há algumas desvantagens na persistência do estado do componente na memória para estar ciente:

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

Pelas razões anteriores, não confie apenas no estado do componente para residir na memória no servidor. Seu aplicativo também deve incluir algum armazenamento de dados de backup para dados entre solicitações. Alguns exemplos simples desta 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 do banco de dados.
• Em um formulário da Web com várias partes, os usuários esperam que seu aplicativo se lembre dos valores entre cada solicitação. Escreva os dados entre cada uma das postagens do usuário em um armazenamento de dados para que possam ser buscados e montados na estrutura de resposta do formulário final quando o formulário com 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 Blazor principal.

Manter o estado com Session

Os desenvolvedores de Web Forms podem manter informações sobre o usuário atualmente em ação com o objeto de Microsoft.AspNetCore.Http.ISession dicionário. É fácil o suficiente para adicionar um objeto com uma chave de cadeia de caracteres para o Session, e esse objeto estaria disponível em um momento posterior durante as interações do usuário com o aplicativo. Em uma tentativa de eliminar o gerenciamento interagindo com HTTP, o Session objeto facilitou a manutenção do estado.

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

A sessão está disponível no ASP.NET Core e no Blazor Server, mas é desencorajada de usar em favor do armazenamento adequado de dados em um repositório de dados. O estado da sessão também não é 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 estado Core e Session está disponível no artigo Session and state management in ASP.NET Core.

Estado do aplicativo

O Application objeto na estrutura de Web Forms fornece um repositório massivo de solicitações cruzadas 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 do aplicativo que seriam referenciadas por todas as solicitações, independentemente do usuário que fizesse a solicitação. O problema com o objeto era que os Application dados não persistiam em vários servidores. O estado do objeto de aplicativo foi perdido entre as reinicializações.

Assim como no Session, é recomendável que os dados sejam movidos para um armazenamento de backup persistente que possa ser acessado por várias instâncias do servidor. Se houver dados voláteis que você gostaria de poder acessar entre solicitações e usuários, você pode 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 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 persistente e recuperado de um armazenamento 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. Existem dois recursos do navegador que permitem a persistência de dados em diferentes escopos do navegador do usuário:

• localStorage - escopo para todo o navegador do usuário. Se a página for recarregada, o navegador for fechado e reaberto, ou outro separador for aberto com o mesmo URL, então o mesmo localStorage é fornecido pelo navegador
• sessionStorage - 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 o seu aplicativo ou fechar e reabrir o navegador, o estado é 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 este pacote para interagir com localStorage e sessionStorage, consulte o artigo Blazor State Management .

AnteriorSeguinte