Azure Functions son las estrellas en la pila sin servidor de Azure: recursos informáticos bajo demanda. Podemos construir funciones para reaccionar a diferentes tipos de eventos, como solicitudes HTTP, procesamiento de archivos o para ejecutar tareas programadas. Pero lo bueno aquí es que si se necesitan más recursos informáticos, Azure escalará automáticamente esos recursos para satisfacer la demanda. Cuando finaliza la alta carga y los recursos ya no son necesarios, Azure se reducirá, incluso a cero, si ese es el caso.
A medida que creamos Azure Functions, debemos mantener nuestro diseño lo más limpio posible. Las funciones se definen para responder a una variedad de factores desencadenantes y ejecutar la lógica empresarial posteriormente. Puede desarrollar funciones ligeras, pero también puede implementar un diseño complejo. Esta publicación trata sobre cómo conectar la inyección de dependencia en Azure Functions para que nuestro código esté más organizado y desacoplado.
Creemos una función de Azure en VS2019. Usando el disparador de Service Bus, estaremos sentados frente a esta estructura:
Echando un vistazo rápido, no veremos ningún Program.cs o Startup.cs, pero si echamos un vistazo a Function1.cs, veremos que se ha pasado la conocida interfaz ILogger. ¿Quién está haciendo esta magia?
Ese es el SDK de funciones de Azure que reconoce la anotación [FunctionName ("Function1")] para el método Run () y [ServiceBusTrigger ()] para el primer parámetro y sabe qué hacer en la compilación. Luego, será el Azure Function Runtime el que iniciará nuestra función y nos pasará el ILogger.
¿Qué pasa si queremos aprovechar la inyección de dependencia para diseñar una aplicación más compleja? ¿Podemos tener algo como Startup.cs y registrar nuestros servicios allí?
De hecho, pero primero, necesitamos instalar un paquete NuGet: Microsoft.Azure.Functions.Extensions, luego podemos crear nuestra clase Startup y hacer que herede de la clase FunctionsStartup presente en el espacio de nombres Microsoft.Azure.Functions.Extensions.DependencyInjection.
En segundo lugar, debemos registrar nuestra clase como Startup, en lugar de la predeterminada utilizada por el tiempo de ejecución. Lo hacemos usando la anotación [assembly] de la siguiente manera:
En este punto, tenemos nuestro objeto IFunctionsHostBuilder y con él, podemos registrar nuestros servicios según sea necesario. Para esta demostración, he creado la interfaz IEventAggregator y la clase EventAggregator. También deberíamos registrar nuestra capacidad de registro.
Por supuesto, podemos utilizar cualquiera de los ciclos de vida de servicio disponibles, como Transient, Singleton o Scoped.
El siguiente paso es inyectar nuestro servicio IEventAggregator en nuestra función. Para eso, necesitamos un poco de refactorización para hacer que nuestra clase de función no sea estática y pasar nuestro servicio a través del constructor.
Y eso es todo, ahora tenemos la clase Startup y nuestro IFunctionsHostBuilder disponibles para registrar los servicios que necesitemos. Recuerde, para que este ejemplo de código funcione, necesita una conexión, suscripción y tema de Azure Service Bus.
¡Espero que esto te ayude y te haga ahorrar una o dos horas en la investigación! 😉 Déjame un comentario si lo hiciste.