Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Sugerencia
Este contenido es un extracto del libro electrónico "Blazor for ASP.NET Web Forms Developers for Azure" (Blazor para desarrolladores de ASP.NET Web Forms), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.
Una aplicación ASP.NET Core se basa en una serie de middleware. El middleware es un controlador que se organiza en un pipeline para gestionar solicitudes y respuestas. En una aplicación de Web Forms, los controladores HTTP y los módulos resuelven problemas similares. En ASP.NET Core, los módulos, controladores, Global.asax.cs y el ciclo de vida de la aplicación se reemplazan por middleware. En este capítulo, obtendrá información sobre el middleware en el contexto de una Blazor aplicación.
Información general
La canalización de solicitudes de ASP.NET Core consiste en una secuencia de delegados de solicitud a los que se llama de uno en uno. En el siguiente diagrama se muestra este concepto. El subproceso de ejecución sigue las flechas negras.
El diagrama anterior carece de un concepto de eventos de ciclo de vida. Este concepto es fundamental para la forma en que se controlan las solicitudes de formularios Web Forms ASP.NET. Este sistema facilita el razonamiento sobre el proceso que está ocurriendo y permite insertar el middleware en cualquier punto. El middleware se ejecuta en el orden en que se agrega a la canalización de solicitudes. También se agregan en código en lugar de archivos de configuración, normalmente en Startup.cs.
Katana
Los lectores familiarizados con Katana se sentirán cómodos en ASP.NET Core. De hecho, Katana es un marco del que se deriva ASP.NET Core. Introdujo patrones de middleware y canalización similares para ASP.NET 4.x. El middleware diseñado para Katana se puede adaptar para trabajar con la canalización de ASP.NET Core.
Middleware común
ASP.NET 4.x incluye muchos módulos. De forma similar, ASP.NET Core también tiene muchos componentes de middleware disponibles. Los módulos de IIS se pueden usar en algunos casos con ASP.NET Core. En otros casos, el middleware nativo ASP.NET Core puede estar disponible.
En la tabla siguiente se enumeran los componentes y middleware de reemplazo en ASP.NET Core.
Módulo | módulo ASP.NET 4.x | opción ASP.NET Core |
---|---|---|
Errores HTTP | CustomErrorModule |
Middleware de páginas de códigos de estado |
Documento predeterminado | DefaultDocumentModule |
Middleware de archivos predeterminados |
Exploración de directorios | DirectoryListingModule |
Middleware de exploración de directorios |
Compresión dinámica | DynamicCompressionModule |
Middleware de compresión de respuesta |
Seguimiento de solicitudes fallidas | FailedRequestsTracingModule |
Gestión de registros de ASP.NET Core |
Almacenamiento en caché de archivos | FileCacheModule |
Middleware de Cacheo de Respuestas |
Almacenamiento en caché HTTP | HttpCacheModule |
Middleware de Cacheo de Respuestas |
Registro HTTP | HttpLoggingModule |
Gestión de registros de ASP.NET Core |
Redireccionamiento HTTP | HttpRedirectionModule |
Middleware de reescritura de URL |
Filtros ISAPI | IsapiFilterModule |
Middleware |
ISAPI | IsapiModule |
Middleware |
Filtrado de solicitudes | RequestFilteringModule |
IRule de middleware de reescritura de URL |
Reescritura de direcciones URL† | RewriteModule |
Middleware de reescritura de URL |
Compresión estática | StaticCompressionModule |
Middleware de compresión de respuesta |
Contenido estático | StaticFileModule |
Middleware de archivos estáticos |
Autorización de direcciones URL | UrlAuthorizationModule |
ASP.NET Core Identity |
Esta lista no es exhaustiva, pero debe dar una idea de qué mapeo existe entre los dos marcos. Para obtener una lista más detallada, consulte Módulos de IIS con ASP.NET Core.
Middleware personalizado
Es posible que el middleware integrado no controle todos los escenarios necesarios para una aplicación. En tales casos, tiene sentido crear su propio middleware. Hay varias maneras de definir middleware, siendo lo más sencillo un delegado simple. Considere el middleware siguiente, que acepta una solicitud de referencia cultural de una cadena de consulta:
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Use(async (context, next) =>
{
var cultureQuery = context.Request.Query["culture"];
if (!string.IsNullOrWhiteSpace(cultureQuery))
{
var culture = new CultureInfo(cultureQuery);
CultureInfo.CurrentCulture = culture;
CultureInfo.CurrentUICulture = culture;
}
// Call the next delegate/middleware in the pipeline
await next();
});
app.Run(async (context) =>
await context.Response.WriteAsync(
$"Hello {CultureInfo.CurrentCulture.DisplayName}"));
}
}
El middleware también se puede definir como clase, ya sea mediante la implementación de la interfaz IMiddleware
o siguiendo una convención de middleware. Para obtener más información, vea Escribir middleware personalizado de ASP.NET Core.