Hay muchas formas de gestionar la inyección de dependencias dentro de nuestras aplicaciones y creo que es importante comprender los beneficios y las limitaciones de los diferentes enfoques. ¡Usar un Autofac   en ASP.NET Core como forma principal de estructurar sus dependencias en lugar de usar el   sugerido es una de esas rutas que podemos explorar! ContainerBuilder AutofacServiceProviderFactory  En este artículo, destaco cómo usar ContainerBuilder de Autofac en su aplicación ASP.NET Core en lugar de AutofacServiceProviderFactory. Veremos lo que puede y no puede hacer con este enfoque en comparación con los otros enfoques a los que tenemos acceso con la inyección de dependencia.  Esto será parte de una serie en la que exploro la resolución de dependencias con Autofac dentro de ASP.NET Core. Me aseguraré de incluir la serie a continuación a medida que se publiquen los números:  Parte 1:  AutofacServiceProviderFactory en ASP.NET Core   Parte 2: Autofac ContainerBuilder en ASP.NET Core: lo que necesita saber   Parte 3: Autofac ComponentRegistryBuilder en ASP.NET Core: cómo registrar dependencias  Al final de esta serie, podrá explorar con más confianza las arquitecturas de complementos dentro de ASP.NET Core y Blazor, lo que le brindará aún más contenido para explorar.  El problema con AutofacServiceProviderFactory  Para ser justos, el título de la sección es *casi* cebo de clics. Creo que el uso de   como   es excelente para la mayoría de las aplicaciones. La gran mayoría de los desarrolladores que quieran utilizar Autofac como su marco de inyección de dependencia preferido no se encontrarían con muchos problemas de esta manera. AutofacServiceProviderFactory forma sugerida de configurar Autofac en sus aplicaciones ASP.NET Core  Nos brinda la capacidad de:  Acceda a   (y a cualquier cosa disponible en este momento) WebApplicationBuilder  Acceso a la instancia de   (también disponible desde la instancia   ) IConfiguration WebApplicationBuilder  Capacidad para pasar dependencias a API mínimas  Pero el gran problema para mí: no podemos acceder a la instancia   . Cuando construyo arquitecturas de complementos en C#, particularmente cuando construyo aplicaciones ASP.NET Core, me gusta tener acceso a la instancia   para registrar rutas. Esto me permite registrar API mínimas de mis complementos con facilidad, lo que técnicamente solo necesita acceso a una implementación de   para obtener la sintaxis útil. WebApplication WebApplication IEndpointRouteBuilder  ¿Puedo registrar API no mínimas sin esto? Absolutamente. ¿Existe otra forma de proporcionar una sintaxis similar y no requerir una instancia   ? Muy probable. Pero en lugar de intentar solucionar ESE problema, quería ver si podía acceder a la dependencia que me interesa. WebApplication  ¡Era hora de cambiar el plan sobre cómo configurar mi contenedor de dependencias!  Exploración de una aplicación ASP.NET Core de muestra  Veamos una aplicación de ejemplo para tener puntos en común que explorar. Si ha   , este será similar: una variación de la aplicación meteorológica de muestra: leído el artículo anterior   using Autofac; using Microsoft.AspNetCore.Mvc; // personal opinion: // I absolutely love having the entry point of my // applications being essentially: // - make my dependencies // - give me the primary dependency // - use it // - ... nothing else :) ContainerBuilder containerBuilder = new(); containerBuilder.RegisterModule<MyModule>(); using var container = containerBuilder.Build(); using var scope = container.BeginLifetimeScope(); var app = scope.Resolve<WebApplication>(); app.Run(); internal record WeatherForecast(DateOnly Date, int TemperatureC, string? Summary) { public int TemperatureF => 32 + (int)(TemperatureC / 0.5556); } internal sealed class MyModule : Module { protected override void Load(ContainerBuilder containerBuilder) { containerBuilder.RegisterType<DependencyA>().SingleInstance(); containerBuilder.RegisterType<DependencyB>().SingleInstance(); containerBuilder.RegisterType<DependencyC>().SingleInstance(); containerBuilder .Register(ctx => { var builder = WebApplication.CreateBuilder(Environment.GetCommandLineArgs()); return builder; }) .SingleInstance(); containerBuilder .Register(ctx => ctx.Resolve<WebApplicationBuilder>().Configuration) .As<IConfiguration>() .SingleInstance(); containerBuilder .Register(ctx => { var builder = ctx.Resolve<WebApplicationBuilder>(); var app = builder.Build(); app.UseHttpsRedirection(); // FIXME: the problem is that the Autofac ContainerBuilder // was used to put all of these pieces together, // but we never told the web stack to use Autofac as the // service provider. // this means that the minimal API will never be able to // find services off the container. we would need to resolve // them BEFORE the API is called, like in this registration // method itself, from the context that is passed in. //DependencyA dependencyA = ctx.Resolve<DependencyA>(); // FIXME: But... What happens if something wants to take a // dependency on the WebApplication instance itself? Once the // web application has been built, there's no more adding // dependencies to it! var summaries = new[] { "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching" }; app.MapGet( "/weatherforecast", ( [FromServices] DependencyA dependencyA , [FromServices] DependencyB dependencyB , [FromServices] DependencyC dependencyC ) => { var forecast = Enumerable .Range(1, 5) .Select(index => new WeatherForecast ( DateOnly.FromDateTime(DateTime.Now.AddDays(index)), Random.Shared.Next(-20, 55), summaries[Random.Shared.Next(summaries.Length)] )) .ToArray(); return forecast; }); return app; }) .SingleInstance(); } } internal sealed class DependencyA( WebApplicationBuilder _webApplicationBuilder); internal sealed class DependencyB( WebApplication _webApplication); internal sealed class DependencyC( IConfiguration _configuration);  Una característica de este enfoque es que usar la clase Autofac   como nuestro contenedor de dependencia principal nos brinda la oportunidad de estructurar nuestro punto de entrada para simplemente: ContainerBuilder  Creación de contenedores  Registro de dependencia  Resolución de dependencia primaria  … ¡Llame a un único método para iniciar la aplicación!  Este es, en mi opinión, el código de inicio de aplicación ideal. ¿Por qué? Porque nunca necesitarás volver aquí para tocarlo. Alguna vez. ¡No importa cuántas cosas agregues! Y eso es todo porque puedes escanear ensamblajes para cargar más módulos.  Nuevamente, esta es una preferencia personal mía y no estoy tratando de afirmar que éste deba ser el objetivo de todos.  Los defectos de Autofac ContainerBuilder en ASP.NET Core  Por supuesto, hay otro enfoque que no es del todo infalible. Así que analicemos lo que NO obtenemos con esta configuración de Autofac:  Los parámetros resueltos por el servicio pasados mediante API mínimas simplemente no funcionan. ¡La   que se creó no está configurada para usar Autofac como marco de inyección de dependencia! WebApplication  Al igual que en el artículo anterior, todavía no podemos obtener la instancia   en el contenedor de dependencia... Así que no hicimos ningún avance específicamente en el acceso a eso. WebApplication  ¡Pero eso es todo! No es una lista terrible de inconvenientes, pero el enfoque de Autofac ContainerBuilder no fue una solución milagrosa para nosotros. Entonces, ¿qué obtuvimos de esto?   también ayudará a explicar lo siguiente: Este video en Autofac   https://youtu.be/FJziGcvuzmo?embedable=true  Los beneficios de Autofac ContainerBuilder en ASP.NET Core  Pros y contras de todo lo que hacemos! Ahora que hemos visto los problemas con Autofac ContainerBuilder en ASP.NET Core, es hora de ver qué avances obtuvimos de esto:  Todavía podemos acceder a las instancias   e   , por lo que es un beneficio comparable al uso del enfoque   . WebApplicationBuilder IConfiguration AutofacServiceProviderFactory  Podemos obtener un punto de entrada muy simplificado a nuestro programa, lo cual realmente me gusta ver. Creación de contenedores, registro, resolución de su método de punto de entrada, ¡y eso es todo!  Las API mínimas funcionan, pero no con dependencias. Aún así, podemos resolver previamente las dependencias que desean las API mínimas y pasarlas en el momento del registro del método. ¡Mira el código comentado!  ¿Más inversión para rutas ASP.NET basadas en complementos?  Vimos que podíamos registrar API mínimas dentro de un método de registro de Autofac, pero desafortunadamente, no podemos resolver las dependencias del contenedor directamente en la llamada API mínima. Podríamos crear una clase dedicada como la siguiente que maneje las definiciones de rutas y las dependencias se resuelvan automáticamente:   internal sealed class WeatherForecastRoutes( DependencyA _dependencyA // FIXME: still can't depend on this because // we can't get the WebApplication //, DependencyB _dependencyB , DependencyC _dependencyC) { private static readonly string[] _summaries = new[] { "Freezing", "Bracing", // ... }; public WeatherForecast[] Forecast() { var forecast = Enumerable.Range(1, 5).Select(index => new WeatherForecast ( DateOnly.FromDateTime(DateTime.Now.AddDays(index)), Random.Shared.Next(-20, 55), _summaries[Random.Shared.Next(_summaries.Length)] )) .ToArray(); return forecast; } }  La resolución automática ocurre si tenemos esta clase Y todas las dependencias en el mismo contenedor. Entonces es sólo cuestión de llamar a este código:   var weatherForecastRoutes = ctx.Resolve<WeatherForecastRoutes>(); app.MapGet("/weatherforecast2", weatherForecastRoutes.Forecast);  Esto todavía apesta un poco desde la perspectiva del complemento porque necesitaríamos resolver todas las clases de ruta manualmente solo para llamar al código de registro de esa manera, todo debido al hecho de que estas cosas no pueden resolver su propio acceso a la   instancia. WebApplication  Pero espera… ¿Qué pasa si le damos la vuelta a las cosas? ¿Qué pasaría si pudiéramos resolver alguna interfaz como   y pasar la instancia   ? IRegisterRoutes WebApplication   // NOTE: make sure to register WeatherForecastRouteRegistrar on the // autofac container as IRegisterRoutes! internal interface IRegisterRoutes { void RegisterRoutes(WebApplication app); } internal sealed class WeatherForecastRouteRegistrar( WeatherForecastRoutes _weatherForecastRoutes) : IRegisterRoutes { public void RegisterRoutes(WebApplication app) { app.MapGet("/weatherforecast2", _weatherForecastRoutes.Forecast); } } // TODO: add this to the autofac code where the // WebApplication instance is built: foreach (var registrar in ctx.Resolve<IEnumerable<IRegisterRoutes>>()) { registrar.RegisterRoutes(app); }  Ahora, ¡ni siquiera necesitamos preocuparnos si nuestros complementos pueden acceder a la instancia   ! Quizás la primera versión no fuera tan limitante después de todo. Quizás estemos en algo aquí... Sin embargo, el próximo artículo debería explicar esto con más detalle. WebApplication  Conclusión de Autofac ContainerBuilder en ASP.NET Core  En este artículo, exploré el uso de Autofac   explícitamente en lugar de usar   como se sugiere normalmente. Vimos algunos beneficios y desventajas similares, pero también un conjunto diferente de cosas a considerar. Cada forma puede ofrecer ventajas y desventajas dependiendo de lo que busque en su aplicación. ContainerBuilder AutofacServiceProviderFactory  Lo interesante fue que si intentamos trabajar con complementos, es posible que ni siquiera necesitemos acceder a la instancia   desde nuestros complementos. Si nos preocupamos por las API mínimas, esto aún podría ser limitante... pero por lo demás, ¡estamos en una línea de pensamiento interesante! WebApplication  Si esto le resultó útil y está buscando más oportunidades de aprendizaje, considere   y vea mis   . suscribirse a mi boletín semanal gratuito de ingeniería de software videos gratuitos en YouTube

This story contains new, firsthand information uncovered by the writer.

Newsletter

Portfolio

Este audio es producido en el idioma original de la historia!

Consejos necesarios para Autofac ContainerBuilder en ASP.NET Core

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

El modelo Bitcoin UTXO, impulsando un ecosistema único

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

El modelo Bitcoin UTXO, impulsando un ecosistema único

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps