Conventions d'injection de dépendances en .NET : durées de vie, portées et piège de la dépendance captive

Ce que c'est

La documentation .NET décrit un conteneur intégré : les services sont ajoutés à un IServiceCollection au démarrage (AddTransient, AddScoped, AddSingleton, ou leurs variantes avec clé), BuildServiceProvider ou l'hôte générique crée l'IServiceProvider, et les consommateurs reçoivent leurs dépendances via un constructeur public. Les services transient sont créés à chaque demande ; les services scoped, une fois par portée, laquelle correspond à la requête dans ASP.NET Core ; les singletons, une fois pour toute la durée de vie du conteneur. Le conteneur libère ce qu'il a créé : les instances transient et scoped à la fin de leur portée, les singletons à l'arrêt. Lorsqu'un type possède plusieurs constructeurs, celui qui possède le plus de paramètres résolubles par injection de dépendances est choisi, et toute ambiguïté déclenche une exception.

Pourquoi c'est important

Les ingénieurs venant de Spring (singleton par défaut) ou de frameworks sans conteneur ont tendance à tout enregistrer en singleton ou à résoudre les services à la main. La page de recommandations nomme le bogue qui en résulte une dépendance captive : un service à plus longue durée de vie retient un service à durée de vie plus courte, si bien qu'un DbContext censé être propre à chaque requête, mais capturé par un singleton, se retrouve partagé silencieusement entre toutes les requêtes. La page consacrée aux durées de vie indique qu'un service scoped ne doit pas être résolu depuis un singleton, que ce soit par injection dans le constructeur ou via IServiceProvider ; la correction documentée consiste à créer une portée explicite avec IServiceScopeFactory.

Comment l'appliquer

• Par défaut, utiliser transient pour les services sans état, scoped pour l'état propre à chaque requête (DbContext, unité de travail), et réserver singleton à un état partagé, utilisable sans risque par plusieurs threads et coûteux ; les recommandations indiquent que les singletons doivent être utilisables sans risque par plusieurs threads et mettent en garde contre le couplage et la consommation mémoire.
• Dépendre d'interfaces dans les constructeurs et n'y effectuer aucun travail autre que des affectations.
• Ne jamais appeler Dispose sur un service injecté, et ne pas enregistrer en transient des types IDisposable susceptibles d'être résolus depuis le fournisseur racine ; les recommandations indiquent que de telles instances sont conservées jusqu'à la libération du conteneur.
• Ne pas appeler BuildServiceProvider pendant la configuration des services, et ne pas utiliser GetService comme un localisateur de services ; les deux figurent parmi les antipatrons recensés.
• Garder la validation des portées activée : l'hôte de développement vérifie que les services scoped ne sont ni résolus depuis la racine ni injectés dans des singletons, et validateScopes: true sur BuildServiceProvider fait de même ailleurs.
• Dans les services hébergés ou d'arrière-plan, injecter IServiceScopeFactory et créer une portée par unité de travail.

Pièges

L'accès statique au fournisseur (un ApplicationServices capturé) figure parmi les pratiques à éviter : les recommandations indiquent que les bénéfices de l'injection de dépendances se perdent lorsqu'elle est mêlée à un accès statique aux objets. Stocker de la configuration ou des données utilisateur dans le conteneur au lieu d'utiliser le modèle des options. Les services à clé nécessitent [FromKeyedServices("key")] sur le paramètre. Enregistrer un service deux fois est autorisé et peut facilement passer inaperçu.