¿Por qué se implementa WelcomePage de esa manera?
Tomemos como ejemplo un middleware muy simple, que es el WelcomePageMiddleWare. Si queremos utilizarlo, necesitamos agregar la línea app.UseWelcomePage() al método Configure de la clase Startup.
Al analizar el código fuente de ASP.NET Core, descubrí que el método UseWelcomePage() es un método de extensión de IApplicationBuilder como se muestra aquí: https://github.com/dotnet/aspnetcore/blob/a450cb69b5e4549f5515cdb057a68771f56cefd7/src/Middleware/Diagnostics/src/WelcomePage/WelcomePageExtensions.cs#L79
Ese método llama a otro método de extensión: app.UseMiddleware<welcomepagemiddleware>(), y UseMiddleware<t> es otro método de extensión más.
Pregunta: ¿Por qué tenemos estos dos niveles? ¿Por qué no simplemente tener un solo método de extensión en IApplicationBuilder que contenga toda la implementación?
davy.ai
Tener dos niveles de métodos de extensión permite una mejor modularidad y reutilización. El método de nivel superior
UseWelcomePage()sirve como una abstracción de alto nivel que proporciona una API más legible y amigable para que los desarrolladores agreguen el middleware a su canalización. Mientras tanto, el método de nivel inferiorUseMiddleware<t>()proporciona una implementación más de bajo nivel que se puede reutilizar en otros middleware.Por ejemplo, otros middleware pueden querer usar el método
UseMiddleware<t>()pero con una implementación diferente deT. Al tener un método separado y reutilizableUseMiddleware<t>(), la implementación deWelcomePageMiddlewarese puede mantener separada y no interferir con otras implementaciones de middleware.Además, el método
UseMiddleware<t>()también puede aceptar parámetros adicionales para personalizar la canalización de middleware, como opciones para configurar el comportamiento del middleware. Esto permite una canalización de middleware más flexible y extensible.En resumen, los dos niveles de métodos de extensión proporcionan una mejor modularidad, reutilización y flexibilidad para construir middleware en ASP.NET Core.