Middleware en ASP.NET Core

En este artículo, entenderemos qué es el middleware en el núcleo de asp.net. Un Middleware es un término muy amplio en asp.net core middleware es una pieza de software que puede manejar una solicitud o respuesta HTTP. Por ejemplo, podemos tener un middleware de un componente que autentica a un usuario, otra pieza de middleware para manejar errores y otro middleware para servir archivos estáticos como archivos JavaScript, archivos CSS, imágenes, etc.

Son estos componentes de middleware los que usamos para configurar una canalización de procesamiento de requests. Es esta canalización la que determina cómo se procesa una solicitud. La canalización de requests se configura como parte del inicio de la aplicación mediante este método de configuración.

Ahora comprendamos cómo funciona el middleware en general en asp.net core. 

Un middleware de un componente en un núcleo enérgico tiene acceso tanto a las requests entrantes como a la respuesta saliente, por lo que en una fusión, un componente puede procesar una solicitud entrante y luego pasar esa solicitud a la siguiente pieza de middleware en la canalización para su posterior procesamiento.

Por ejemplo, digamos que el middleware de registro es el primer middleware en nuestra canalización de procesamiento de requests de aplicaciones, por lo que cuando llega una solicitud del servidor web, este middleware registra la hora en que se recibe la solicitud y luego pasa esa solicitud entrante a la siguiente pieza de middleware en nuestro En el caso del middleware de archivos estáticos para su posterior procesamiento, un componente de middleware puede manejar las requests entrantes y decidir no llamar a la siguiente pieza de middleware en la canalización, esto se denomina cortocircuito.

Se recomienda acortar la canalización de requests porque evita trabajo innecesario, por ejemplo, si la solicitud se realiza para obtener archivos estáticos (imagen, CSS, archivos JavaScript, etc.). Con estos archivos estáticos, el middleware puede manejar y atender esa solicitud y luego cortocircuitar el resto de la canalización, lo que significa, en nuestro caso, los archivos estáticos. Un Middleware no llamará a la siguiente pieza de middleware que es el middleware MVC si la solicitud es para un archivo estático como una imagen.

Por ejemplo, un componente de middleware también puede simplemente ignorar la solicitud entrante y luego pasar esa solicitud a la siguiente pieza de middleware para su posterior procesamiento. digamos que esta vez estamos emitiendo una solicitud a un host local para /employees básicamente queremos recuperar la lista de todos los empleados, de modo que cuando llegue esta solicitud del servidor web a nuestro primer middleware en la tubería que está registrando este middleware simplemente registra la hora se recibe la solicitud, y luego pasa esa solicitud a la siguiente pieza de middleware en nuestro caso al middleware de archivos estáticos ya que esta solicitud no es para un archivo estático como un archivo JavaScript de archivo CSS de imagen, etc. 

Es posible que el middleware de archivos estáticos no esté interesado en procesar esta solicitud, por lo que simplemente pasará esa solicitud a la siguiente pieza de middleware, que es el middleware MVC. Esta es una solicitud MVC, por lo que el middleware MVC sabe cómo manejar esa solicitud para que el controlador MVC respectivo produzca el La respuesta HTTP en este punto, la tubería se invierte, el middleware MVC pasa esa respuesta a los archivos estáticos, donde el middleware de archivos estáticos no está interesado en procesar esa respuesta más, por lo que simplemente puede pasar esa responsabilidad a la siguiente pieza de middleware que es el registro de middleware. Este middleware puede simplemente bloquear la hora en que se recibe la respuesta. Recuerde que este middleware de registro también tiene la hora en que recibió la solicitud. Por lo tanto, al usar estos dos tiempos, también puede calcular el tiempo total necesario para atender esa solicitud y luego pasar esa respuesta al servidor web, a su vez, puede enviar esa respuesta al cliente que realizó la solicitud, por lo que son estos componentes de middleware en la canalización los que determinan Cómo se procesa una solicitud en un núcleo dividido o neto. Estos componentes de middleware se ejecutan en el orden en que se agregan a la canalización. Se debe tener cuidado para agregar el middleware en el orden correcto. de lo contrario, es posible que la aplicación no funcione como se esperaba.

Para usar el middleware en la aplicación, usando los delegados de solicitud, tenemos que construir la tubería de solicitud que maneja la solicitud HTTP. Podemos configurar los delegados de solicitud a través de los métodos ‘Ejecutar’, ‘Mapa’ y ‘Usar’ en IApplicationBuilder.

Estos delegados decidirán si la solicitud debe pasar al siguiente componente en la canalización de la aplicación o no. También puede realizar acciones como guardar datos, antes y después de la invocación del siguiente componente en la canalización de la aplicación. Luego, la respuesta regresa de manera similar a través de la canalización.