Il existe de nombreuses façons de gérer l'injection de dépendances dans nos applications, et je pense qu'il est important de comprendre les avantages et les limites des différentes approches. Utiliser un Autofac   dans ASP.NET Core comme principal moyen de structurer vos dépendances au lieu d'utiliser l'   suggéré est l'une de ces voies que nous pouvons explorer ! ContainerBuilder AutofacServiceProviderFactory  Dans cet article, je souligne comment utiliser ContainerBuilder d'Autofac dans votre application ASP.NET Core au lieu d'AutofacServiceProviderFactory. Nous examinerons ce que vous pouvez et ne pouvez pas faire avec cette approche par rapport aux autres approches auxquelles nous avons accès avec l'injection de dépendances.  Cela fera partie d'une série dans laquelle j'explore la résolution des dépendances avec Autofac dans ASP.NET Core. Je ne manquerai pas d'inclure la série ci-dessous au fur et à mesure que les numéros seront publiés :  Partie 1 :  AutofacServiceProviderFactory dans ASP.NET Core   Partie 2 : Autofac ContainerBuilder dans ASP.NET Core – Ce que vous devez savoir   Partie 3 : Autofac ComponentRegistryBuilder dans ASP.NET Core – Comment enregistrer les dépendances  À la fin de cette série, vous serez en mesure d'explorer avec plus de confiance les architectures de plugins dans ASP.NET Core et Blazor, ce qui vous fournira encore plus de contenu à explorer.  Le problème avec AutofacServiceProviderFactory  Pour être honnête, le titre de la section est *presque* un appât à clics. Je pense que l'utilisation   comme   est idéale pour la plupart des applications. La grande majorité des développeurs qui souhaitent utiliser Autofac comme cadre d'injection de dépendances de choix ne rencontreraient pas beaucoup de problèmes de cette façon. AutofacServiceProviderFactory moyen suggéré pour configurer Autofac dans vos applications ASP.NET Core  Cela nous offre la possibilité de :  Accédez à   (et à tout ce qui est disponible à ce stade) WebApplicationBuilder  Accès à l'instance de   (également disponible hors de l'instance   ) IConfiguration WebApplicationBuilder  Possibilité de transmettre les dépendances sur un minimum d'API  Mais le gros problème pour moi : nous ne pouvons pas accéder à l'instance   . Lorsque je crée des architectures de plugins en C#, en particulier lors de la création d'applications ASP.NET Core, j'aime avoir accès à l'instance   afin d'enregistrer des routes. Cela me permet d'enregistrer facilement un minimum d'API de mes plugins, qui techniquement n'ont besoin que d'accéder à une implémentation de   pour obtenir la syntaxe pratique. WebApplication WebApplication IEndpointRouteBuilder  Puis-je enregistrer des API non minimales sans cela ? Absolument. Existe-t-il un autre moyen de fournir une syntaxe similaire et de ne pas nécessiter d'instance   ? Très probable. Mais au lieu d'essayer de contourner CE problème, je voulais voir si je pouvais simplement accéder à la dépendance qui m'intéresse. WebApplication  Il était temps de changer le plan de configuration de mon conteneur de dépendances !  Explorer un exemple d'application ASP.NET Core  Examinons un exemple d'application afin d'avoir un terrain d'entente à explorer. Si vous avez   , cela ressemblera à une variante de l'exemple d'application météo : lu l'article précédent   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);  L'un des points forts de cette approche est que l'utilisation de la classe Autofac   comme conteneur de dépendances principal nous offre la possibilité de structurer notre point d'entrée simplement : ContainerBuilder  Création de conteneur  Enregistrement des dépendances  Résolution des dépendances primaires  … Appelez une seule méthode pour démarrer l’application !  C'est, à mon avis, le code de démarrage d'application idéal. Pourquoi? Parce que vous n’avez jamais besoin de revenir ici pour y toucher. Jamais. Peu importe le nombre de choses que vous ajoutez ! Et c'est tout parce que vous pouvez numériser des assemblys pour charger plus de modules.  Encore une fois, c'est une de mes préférences personnelles, et je n'essaie pas de prétendre que cela devrait être l'objectif de tout le monde.  Les défauts d'Autofac ContainerBuilder dans ASP.NET Core  Bien sûr, il s’agit d’une autre approche qui n’est pas tout à fait à l’épreuve des balles. Discutons donc de ce que nous n'obtenons PAS avec cette configuration d'Autofac :  Les paramètres résolus par le service transmis sur des API minimales ne fonctionnent tout simplement pas. L'   qui a été construite n'est pas configurée pour utiliser Autofac comme framework d'injection de dépendances ! WebApplication  Comme dans l'article précédent, nous ne parvenons toujours pas à obtenir l'instance   sur le conteneur de dépendances… Nous n'avons donc fait aucune avancée spécifique pour y accéder. WebApplication  Mais c'est surtout ça ! Ce n'est pas une liste terrible d'inconvénients, mais l'approche Autofac ContainerBuilder n'était pas une solution miracle pour nous. Alors, qu’en avons-nous retiré ?   aidera également à expliquer les éléments suivants : Cette vidéo sur Autofac   https://youtu.be/FJziGcvuzmo?embedable=true  Les avantages d'Autofac ContainerBuilder dans ASP.NET Core  Avantages et inconvénients de tout ce que nous faisons ! Maintenant que nous avons vu les problèmes liés à Autofac ContainerBuilder dans ASP.NET Core, il est temps d'examiner les avancées que nous en avons retirées :  Nous pouvons toujours accéder aux instances   et   , c'est donc un avantage comparable à l'utilisation de l'approche   . WebApplicationBuilder IConfiguration AutofacServiceProviderFactory  Nous pouvons obtenir un point d’entrée très simplifié à notre programme, ce que j’aime vraiment voir. Création de conteneur, enregistrement, résolution de votre méthode de point d'entrée, et c'est tout !  Les API minimales fonctionnent, mais pas avec les dépendances. Néanmoins, nous pouvons pré-résoudre les dépendances souhaitées par les API minimales et les transmettre au moment de l'enregistrement de la méthode. Voir le code commenté !  Plus d'inversion pour les routes ASP.NET basées sur des plugins ?  Nous avons vu que nous pouvions enregistrer des API minimales au sein d'une méthode d'enregistrement Autofac, mais malheureusement, nous ne pouvons pas résoudre les dépendances du conteneur directement sur l'appel d'API minimal lui-même. Nous pourrions créer une classe dédiée comme la suivante qui gère les définitions de routes avec des dépendances résolues automatiquement :   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 résolution automatique se produit si nous avons cette classe ET les dépendances sur le même conteneur. Il suffit ensuite d'appeler ce code :   var weatherForecastRoutes = ctx.Resolve<WeatherForecastRoutes>(); app.MapGet("/weatherforecast2", weatherForecastRoutes.Forecast);  Cela craint encore un peu du point de vue du plugin, car nous aurions besoin de résoudre manuellement toutes les classes de route juste pour appeler le code d'enregistrement comme ça - tout cela provenant du fait que ces choses ne peuvent pas résoudre leur propre accès à l'   exemple. WebApplication  Mais attendez… Et si nous retournions les choses ? Et si nous pouvions résoudre une interface comme   et transmettre l'instance   ?! 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); }  Désormais, nous n'avons même plus besoin de nous soucier de savoir si l'instance   est accessible à nos plugins ! Peut-être que la première version n'était pas si restrictive après tout. Peut-être que nous sommes sur quelque chose ici… Cependant, le prochain article devrait expliquer cela plus en détail. WebApplication  Conclusion d'Autofac ContainerBuilder dans ASP.NET Core  Dans cet article, j'ai exploré l'utilisation explicite d'un Autofac   au lieu d'utiliser   comme cela est normalement suggéré. Nous avons constaté des avantages et des inconvénients similaires, mais également un ensemble différent de facteurs à prendre en compte. Chaque méthode peut présenter des avantages et des inconvénients en fonction de ce que vous recherchez dans votre candidature. ContainerBuilder AutofacServiceProviderFactory  Ce qui était intéressant, c'est que si nous essayons de travailler sur des plugins, nous n'aurons peut-être même pas besoin d'accéder à l'instance   à partir de nos plugins ! Si l’on se soucie d’API minimales, cela peut quand même être limitant… mais sinon, nous sommes dans une réflexion intéressante ! WebApplication  Si vous avez trouvé cela utile et que vous recherchez davantage d'opportunités d'apprentissage, pensez à   et regardez mes   ! vous abonner à ma newsletter hebdomadaire gratuite sur le génie logiciel vidéos gratuites sur YouTube

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

Newsletter

Portfolio

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Make resilience your competitive advantage

Besoin de connaître les conseils pour Autofac ContainerBuilder dans ASP.NET Core

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps