Como sabemos, ASP.NET Core incluye un sistema de inyección de dependencias que, aunque es algo simple comparado con otras alternativas más veteranas, cubre la mayoría de necesidades habituales. Por ejemplo, un aspecto que no es muy conocido y que puede ser útil en muchas ocasiones es su capacidad para registrar y recuperar múltiples implementaciones de una misma interfaz.

En este post vamos a ver cómo conseguirlo, y un caso práctico de uso de esta técnica en un escenario muy frecuente.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• 101 formas de saber que tu proyecto está condenado al fracaso
  José María Aguilar
• Generar redirecciones HTTP 307 y 308 en ASP.NET Core MVC
  José María Aguilar

.NET / .NET Core

• Historia de C#
  Fernando Escolar
• AppSettings.json, an unfortunate name?
  Daniel Wertheim
• Advanced C# - Dynamic Type
  Marinko Spasojevic
• C# 8 is fixing interpolated verbatim strings – Developers Anonymous
  John Demetriou
• An extension method for .NET enumerations that uses the DescriptionAttribute
  Jeremy Lindsay
• Fixing Random, part 2
  Eric Lippert
• Working with types in a Roslyn analyzer
  Gérald Barré
• C# 8: Nullable Reference Types
  Dawid Sibiński
• C# Futures: Lambda Attributes & Static Delegates and Function Pointers
  Jonathan Allen
• How many keywords I can fit into a single C# expression?
  Jiří Činčura
• New Jasper Alpha for HTTP Services
  Jeremy D. Miller
• Brainstorming - Creating a small single self-contained executable out of a .NET Core application
  Scott Hanselman
• How to debug .NET Deadlocks (C# Deadlocks in Depth - Part 3)
  Michael Shpilt
• Cómo guardar "secretos" en nuestras aplicaciones de .NET Core (sin peligro de enviarlos a GitHub por error)
  Jorge Turrado

Tradicionalmente los middlewares de ASP.NET Core los hemos implementado como clases independientes más o menos con la siguiente pinta:

public class MyCustomMiddleware
{
    private readonly RequestDelegate _next;
    public MyCustomMiddleware(RequestDelegate next)
    {
        _next = next;
    }
 
    public async Task Invoke(HttpContext context)
    {
        // Hacer algo antes de pasar el control al siguiente middleware
        await _next(context); // Pasar el control al siguiente middleware
        // Hacer algo después de ejecutar el siguiente middleware
    }
}

Estas clases no heredan de ninguna otra ni implementan interfaces proporcionadas por el framework, aunque atienden a convenciones simples, como la recepción en el constructor del delegado al siguiente middleware en el pipeline, o la existencia de un método Invoke() o InvokeAsync(), que es donde introduciremos nuestra lógica, recibiendo el contexto HTTP.

La ausencia de interfaces o clases base aporta flexibilidad, pero elimina las ayudas propias del tipado fuerte y puede ser fuente de problemas si no atendemos a estas convenciones con cuidado. Es decir, si en lugar del método Invoke() por error escribimos Invke(), nada fallará en compilación. Tendremos que esperar a ejecutar la aplicación para que explote.

También es importante tener en cuenta que una clase middleware sólo es instanciada una vez, cuando la aplicación está arrancando; luego, en cada petición será ejecutado su método Invoke() sobre la misma instancia, lo que es a priori muy poco intuitivo y puede causarnos algún dolor de cabeza si no somos cuidadosos.

Ahí van los enlaces recopilados durante la semana pasada. Espero que os resulten interesantes. :-)

Por si te lo perdiste...

• Programadores con producción neta negativa (NNPP)
  José María Aguilar
• ¿Aún usas ToString() para obtener el nombre de los elementos de un enum?
  José María Aguilar

.NET / .NET Core

• Announcing .NET Core 3 Preview 2
  Rich Lander
• Introducing the .NET Community Standup Series
  James Montemagno
• Generate disassembly of .NET functions
  Wojciech Nagórski
• Tic Tac Toe Using AI –The Easy Way
  George Swan
• Designing Data Objects in C#: More examples
  Yacoub Massad
• yield return await and await foreach geekery
  Jiří Činčura
• C# 8 using declarations
  Kevin Jones
• C# Interface: Definition, Examples, Best Practices, and Pitfalls
  Phil Vuollet
• System.Collections in .NET Core 3.0
  Jonathan Allen
• WTF Is a Lambda
  Jon Hilton
• [C#] Have some fun with .net core startup hooks
  Kévin Gosse
• Dependency Hell
  Damian Laczak
• Is WPF Still Relevant in 2019?
  Claudio Bernasconi
• Update on IAsyncDisposable and IAsyncEnumerator
  Jonathan Allen
• Fixing random, part 1
  Eric Lippert

Sin duda, entre las mejoras incluidas en ASP.NET Core 2.2 destaca especialmente el nuevo modelo de hosting in-process para IIS, que promete cuadriplicar el rendimiento prácticamente sin hacer ningún cambio en nuestras aplicaciones, siempre que las ejecutemos en un entorno Windows/IIS.

Como recordaréis, se trata de una mejora en el módulo ASP.NET Core (ANCM) que hace que las aplicaciones se ejecuten directamente dentro del worker del servidor web (w3wp.exe), evitando las llamadas internas producidas cuando IIS actuaba como un mero proxy inverso.

Por verlo gráficamente, el siguiente diagrama muestra la arquitectura tradicional de un sistema ASP.NET Core funcionando sobre IIS. En el modelo out-of-process utilizado hasta ASP.NET Core 2.1, cada petición realizada desde el exterior era capturada por IIS, que a su vez lanzaba una petición HTTP local con los mismos contenidos hacia Kestrel, que era quien la procesaba ejecutando nuestro código. La respuesta generada desde Kestrel era enviada de vuelta a IIS como respuesta a la petición, quien la retornaba al agente de usuario:



En este modelo de funcionamiento, por tanto, cada petición HTTP entrante generaba otra petición HTTP interna que, aunque estuviera dentro de la misma máquina, imponía una penalización importante en el rendimiento de las aplicaciones.

El hosting in-process, aparecido con ASP.NET Core 2.2, cambia las reglas del juego eliminando esas peticiones HTTP internas y los retardos que implicaban, lo que ha posibilitado el espectacular incremento en el rendimiento que su uso ofrece. Ahora, el módulo para IIS ejecuta internamente la aplicación y se comunica con ella de forma directa:



Este es el modo por defecto de los nuevos proyectos ASP.NET Core creados usando las plantillas estándar, algo que podemos claramente ver si echamos un vistazo al archivo .csproj de un proyecto recién creado, ya sea desde Visual Studio o desde .NET Core CLI:

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>

Si tenéis un proyecto ASP.NET Core 2.1 o anterior y lo actualizáis a 2.2, tendréis que añadir el elemento <AspNetCoreHostingModel> de forma manual para usar este modelo de ejecución.

Sin embargo, estas mejoras espectaculares no son gratis del todo, y creo que es interesante conocer un poco mejor lo que implica asumir este nuevo modo de funcionamiento de nuestras aplicaciones y responder a algunas preguntas que podríamos hacernos por el camino.