Administración de estados

Sugerencia

Este contenido es un extracto del libro electrónico Blazor para desarrolladores de ASP NET Web Forms para Azure, disponible en documentos de .NET o como un PDF descargable gratuito que se puede leer sin conexión.

Descargar PDF

La administración de estados es un concepto clave de las aplicaciones de Formularios Web Forms, que se facilita a través de las características ViewState, Session State, Application State y Postback. Estas características con estado del marco ayudaron a ocultar la administración de estado necesaria para una aplicación y permiten a los desarrolladores de aplicaciones centrarse en ofrecer su funcionalidad. Con ASP.NET Core y Blazor, algunas de estas características se han reubicado y algunas se han quitado por completo. En este capítulo se revisa cómo mantener el estado y ofrecer la misma funcionalidad con las nuevas características de Blazor.

Solicitud de administración de estado con ViewState

Al analizar la administración de estado en la aplicación de Formularios Web Forms, muchos desarrolladores pensarán inmediatamente en ViewState. En Web Forms, ViewState gestiona el estado del contenido entre las solicitudes HTTP enviando un bloque de texto codificado de gran tamaño de ida y vuelta al navegador. El campo ViewState podría sobrecargarse con el contenido de una página que contiene muchos elementos, lo que podría expandirse a varios megabytes de tamaño.

Con Blazor Server, la aplicación mantiene una conexión continua con el servidor. El estado de la aplicación, denominado circuito, se mantiene en la memoria del servidor mientras la conexión se considera activa. El estado solo se eliminará cuando el usuario salga de la aplicación o de una página determinada de la aplicación. Todos los miembros de los componentes activos están disponibles entre interacciones con el servidor.

Hay varias ventajas de esta característica:

• El estado del componente está disponible fácilmente y no se vuelve a generar entre las interacciones.
• El estado no se transmite al explorador.

Sin embargo, hay algunas desventajas en la persistencia del estado del componente en memoria para tener en cuenta:

• Si el servidor se reinicia entre la solicitud, se pierde el estado.
• La solución de equilibrio de carga del servidor web de la aplicación debe incluir sesiones permanentes para asegurarse de que todas las solicitudes del mismo explorador vuelvan al mismo servidor. Si una solicitud va a otro servidor, se perderá el estado.
• La persistencia del estado de componente en el servidor puede provocar presión de memoria en el servidor web.

Por las razones anteriores, no dependa solo de que el estado del componente permanezca en la memoria del servidor. La aplicación también debe incluir algún almacén de datos de respaldo para los datos entre solicitudes. Algunos ejemplos sencillos de esta estrategia:

• En una aplicación de carro de la compra, conserve el contenido de los nuevos elementos agregados al carro en un registro de base de datos. Si se pierde el estado en el servidor, puede reconstituirlo de los registros de la base de datos.
• En un formulario web de varios elementos, los usuarios esperarán que la aplicación recuerde valores entre cada solicitud. Escriba los datos entre cada una de las publicaciones del usuario en un almacén de datos para que se puedan capturar y ensamblar en la estructura de respuesta del formulario final cuando se complete el formulario de varias partes.

Para obtener más información sobre cómo administrar el estado en las aplicaciones blazor, consulte ASP.NET Administración de estado de Blazor core.

Mantenimiento del estado con Session

Los desarrolladores de Web Forms pueden mantener información sobre el usuario activo actual con el objeto de diccionario Microsoft.AspNetCore.Http.ISession. Es lo suficientemente fácil agregar un objeto con una clave de cadena a Sessiony ese objeto estaría disponible más adelante durante las interacciones del usuario con la aplicación. En un intento de eliminar la administración de la interacción con HTTP, el Session objeto facilita el mantenimiento del estado.

La firma del objeto de .NET Framework Session no es la misma que el objeto ASP.NET Core Session . Tenga en cuenta la documentación de la nueva sesión principal de ASP.NET antes de decidir migrar y usar la nueva característica de estado de sesión.

La sesión está disponible en ASP.NET Core y Blazor Server, pero se desaconseja su uso en favor del almacenamiento de datos en un repositorio de manera adecuada. El estado de sesión tampoco es funcional si los visitantes rechazan el uso de cookies HTTP en la aplicación debido a problemas de privacidad.

La configuración para ASP.NET Core y estado de sesión está disponible en el artículo Administración de estado y sesión en ASP.NET Core.

Estado de la aplicación

El Application objeto del marco de Web Forms proporciona un repositorio masivo de solicitudes cruzadas para interactuar con la configuración y el estado del ámbito de la aplicación. El estado de la aplicación era un lugar ideal para almacenar varias propiedades de configuración de aplicaciones a las que se haría referencia en todas las solicitudes, independientemente del usuario que realice la solicitud. El problema con el Application objeto era que los datos no persistieron en varios servidores. El estado del objeto de aplicación se perdió entre reinicios.

Al igual que con Session, se recomienda que los datos se muevan a un almacén de respaldo persistente al que varias instancias de servidor puedan tener acceso. Si hay datos volátiles a los que le gustaría poder acceder a través de solicitudes y usuarios, podría almacenarlo fácilmente en un servicio singleton que se pueda insertar en componentes que requieran esta información o interacción.

La construcción de un objeto para mantener el estado de la aplicación y su consumo podría parecerse a la siguiente implementación:

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>

El MyApplicationState objeto se crea una sola vez en el servidor y el valor VisitorCounter se captura y genera en la etiqueta del componente. El VisitorCounter valor debe conservarse y recuperarse de un almacén de datos de respaldo para la durabilidad y la escalabilidad.

En el explorador

Los datos de la aplicación también se pueden almacenar en el lado cliente en el dispositivo del usuario para que esté disponible más adelante. Hay dos características del explorador que permiten la persistencia de datos en distintos ámbitos del explorador del usuario:

• localStorage : tiene como ámbito todo el explorador del usuario. Si se vuelve a cargar la página, el explorador se cierra y vuelve a abrir, u otra pestaña se abre con la misma dirección URL, el explorador proporciona lo mismo localStorage .
• sessionStorage : tiene como ámbito la pestaña actual del explorador del usuario. Si se vuelve a cargar la pestaña, el estado persiste. Sin embargo, si el usuario abre otra pestaña en la aplicación o cierra y vuelve a abrir el explorador, se pierde el estado.

Puede escribir código JavaScript personalizado para interactuar con estas características o hay una serie de paquetes NuGet que puede usar para proporcionar esta funcionalidad. Uno de estos paquetes es Microsoft.AspNetCore.ProtectedBrowserStorage.

Para obtener instrucciones sobre cómo usar este paquete para interactuar con localStorage y sessionStorage, consulte el artículo Administración de estado de Blazor .

Siguiente anterior