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.
La administración de estados es un concepto clave de las aplicaciones de Web Forms, que se proporciona por medio de las características Ver estado, Estado de la sesión, Estado de la aplicación y Postback. Estas características con estado del marco han ayudado a ocultar la administración de estado necesaria para una aplicación y permitir a los desarrolladores de aplicaciones centrarse en la entrega de su funcionalidad. Con ASP.NET Core y Blazor, algunas de estas características se han reubicado y otras se han eliminado por completo. En este capítulo se describe cómo mantener el estado y ofrecer la misma funcionalidad con las nuevas características de Blazor.
Solicitud de la administración de estado con ViewState
Al examinar la administración de estado en una aplicación de Web Forms, muchos desarrolladores pensarán inmediatamente en ViewState. En Web Forms, ViewState administra el estado del contenido entre las solicitudes HTTP mediante el envío de ida y vuelta al explorador de un bloque de texto codificado grande. El campo ViewState podría saturarse con el contenido de una página que contiene muchos elementos, y podría llegar a alcanzar un tamaño de varios megabytes.
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 navegue fuera de la aplicación o a una página concreta de esta. Todos los miembros de los componentes activos están disponibles entre las interacciones con el servidor.
Esta característica ofrece varias ventajas:
- El estado del componente está disponible fácilmente y no se vuelve a generar entre las interacciones.
- El estado no se transmite al explorador.
Pero hay algunas desventajas de la persistencia del estado del componente en memoria que debe tener en cuenta:
- Si el servidor se reinicia entre las solicitudes, el estado se pierde.
- 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 procedentes del mismo explorador vuelvan al mismo servidor. Si una solicitud va a otro servidor, se perderá el estado.
- La persistencia del estado del componente en el servidor puede provocar presión de memoria en el servidor web.
Por los motivos anteriores, no confíe solo en el estado del componente para almacenarlo en memoria en el servidor. La aplicación también debe incluir algún almacén de datos de respaldo para los datos entre las solicitudes. Algunos ejemplos sencillos de esta estrategia son los siguientes:
- En una aplicación de carro de la compra, conserve en un registro de base de datos el contenido de los nuevos artículos que se agregan. Si se pierde el estado en el servidor, puede restaurarlo a partir de los registros de la base de datos.
- En un formulario web de varias partes, los usuarios esperarán que la aplicación recuerde los valores entre cada solicitud. Escriba los datos entre cada una de las entradas del usuario en un almacén de datos para que se puedan capturar y ensamblar en la estructura de respuesta de 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, vea Administración de estado de Blazor en ASP.NET 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 bastante fácil agregar un objeto con una clave de cadena a Session, y ese objeto estará disponible después durante las interacciones del usuario con la aplicación. En un intento de eliminar la administración de la interacción con HTTP, el objeto Session ha facilitado el mantenimiento del estado.
La signatura del objeto Session de .NET Framework no es la misma que la del objeto Session de ASP.NET Core. Tenga en cuenta la documentación de la nueva sesión de ASP.NET Core antes de decidir si migrar y usar la nueva característica de estado de sesión.
Session está disponible en ASP.NET Core y Blazor Server, pero antes de usarlo, se recomienda almacenar los datos en un repositorio de datos de forma 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 de ASP.NET Core y el estado de sesión está disponible en el artículo Administración del estado y la sesión en ASP.NET Core.
Estado de la aplicación
El objeto Application del marco Web Forms proporciona un repositorio masivo entre solicitudes 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 la aplicación a las que se hacía referencia en todas las solicitudes, independientemente del usuario que realizara la solicitud. El problema con el objeto Application era que los datos no se conservaban entre varios servidores. El estado del objeto de aplicación se perdía entre reinicios.
Como sucede con Session, se recomienda trasladar los datos a una memoria auxiliar persistente a la que puedan acceder varias instancias de servidor. Si hay datos volátiles a los que quiera poder acceder entre solicitudes y usuarios, puede almacenarlos fácilmente en un servicio singleton que se puede insertar en componentes que necesiten 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 ser similar a la implementación siguiente:
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 objeto MyApplicationState solo se crea una vez en el servidor, y el valor VisitorCounter se captura y se muestra en la etiqueta del componente. El valor VisitorCounter se debe conservar y recuperar 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én disponibles más adelante. Hay dos características del explorador que permiten la persistencia de los datos en diferentes ámbitos del explorador del usuario:
localStorage: el ámbito es la totalidad del explorador del usuario. Si se vuelve a cargar la página, se cierra el explorador y se vuelve a abrir, o bien se abre otra pestaña con la misma dirección URL, el explorador proporciona el mismo elementolocalStorage.sessionStorage: el ámbito es la pestaña actual del explorador del usuario. Si se recarga la pestaña, el estado se conserva. Pero si el usuario abre otra pestaña en la aplicación o cierra y vuelve a abrir el explorador, el estado se pierde.
Puede escribir código de JavaScript personalizado para interactuar con estas características, o bien usar una serie de paquetes NuGet para proporcionar esta funcionalidad. Uno de estos paquetes es Microsoft.AspNetCore.ProtectedBrowserStorage.
Para obtener instrucciones sobre el uso de este paquete a fin de interactuar con localStorage y sessionStorage, vea el artículo Administración de estado de Blazor.
