{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quelle est la principale différence entre les lifetimes Singleton, Scoped et Transient ?","acceptedAnswer":{"@type":"Answer","text":"Singleton crée une seule instance pour toute la durée de vie de l'application, Scoped crée une instance par requête HTTP (ou scope), et Transient crée une nouvelle instance à chaque injection. Ces lifetimes déterminent quand et combien de fois le conteneur DI instancie un service. Utiliser Singleton pour des services sans état partagés, Scoped pour des services liés à une requête (comme DbContext), et Transient pour des services légers sans état partagé."}},{"@type":"Question","name":"Quel lifetime utiliser pour enregistrer un DbContext Entity Framework Core ?","acceptedAnswer":{"@type":"Answer","text":"DbContext doit être enregistré avec un lifetime Scoped car il n'est pas thread-safe et maintient un état de tracking des entités. Chaque requête HTTP doit avoir sa propre instance de DbContext pour éviter les problèmes de concurrence. L'enregistrement se fait avec AddDbContext qui configure automatiquement le lifetime Scoped. Utiliser Singleton causerait des erreurs de concurrence, et Transient gaspillerait des ressources en créant trop d'instances."}},{"@type":"Question","name":"Comment enregistrer un service avec une interface et son implémentation ?","acceptedAnswer":{"@type":"Answer","text":"L'enregistrement d'un service se fait avec les méthodes AddSingleton, AddScoped ou AddTransient en spécifiant l'interface comme type de service et la classe concrète comme implémentation. La syntaxe est services.Add{Lifetime}(). Cette approche permet de respecter le principe de dépendance par abstraction et facilite les tests en permettant de substituer des implémentations. Le conteneur DI résoudra automatiquement l'implémentation concrète lors de l'injection de l'interface."}},{"@type":"Question","name":"Dans quel cas privilégier AddSingleton plutôt que AddScoped ?","acceptedAnswer":{"@type":"Answer","text":"AddSingleton est adapté pour des services sans état partagés dans toute l'application (configuration, cache, logging) car ils sont créés une seule fois et partagés entre toutes les requêtes. AddScoped est préférable pour des services qui maintiennent un état lié à une requête spécifique (DbContext, services métier avec contexte utilisateur). Singleton améliore les performances en évitant les allocations répétées mais nécessite que le service soit thread-safe. Éviter Singleton pour des services avec état mutable ou des dépendances sur des services Scoped."}},{"@type":"Question","name":"Quel est le rôle de IServiceProvider dans le système de DI ?","acceptedAnswer":{"@type":"Answer","text":"IServiceProvider est le conteneur de services qui résout et fournit les instances de services enregistrés. Il expose les méthodes GetService et GetRequiredService pour récupérer des instances. Le conteneur gère automatiquement la création, le cycle de vie et la disposal des services selon leur lifetime. Il est construit via ServiceCollection.BuildServiceProvider() et injecté automatiquement dans les services qui en ont besoin. Éviter de l'injecter directement (anti-pattern Service Locator) sauf cas spécifiques comme les factories."}},{"@type":"Question","name":"Comment résoudre manuellement un service depuis IServiceProvider ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser GetService() pour une résolution optionnelle qui retourne null si le service n'existe pas, ou GetRequiredService() qui lance une exception si le service est introuvable. La résolution manuelle est découragée dans les constructeurs (utiliser l'injection par constructeur à la place) mais acceptable dans les factories ou certains cas spécifiques. Pour des services Scoped, créer un scope avec CreateScope() avant de résoudre. Toujours préférer l'injection par constructeur pour respecter les bonnes pratiques de DI."}},{"@type":"Question","name":"Quelle est la différence entre GetService et GetRequiredService ?","acceptedAnswer":{"@type":"Answer","text":"GetService() retourne null si le service n'est pas enregistré, permettant une résolution optionnelle avec gestion de null. GetRequiredService() lance une InvalidOperationException si le service est introuvable, garantissant une instance non-null. Utiliser GetRequiredService pour des dépendances critiques obligatoires, et GetService pour des dépendances optionnelles. GetRequiredService évite les null reference exceptions et documente explicitement les dépendances obligatoires. En pratique, préférer GetRequiredService sauf besoin explicite de dépendance optionnelle."}},{"@type":"Question","name":"Comment enregistrer plusieurs implémentations pour une même interface ?","acceptedAnswer":{"@type":"Answer","text":"Enregistrer chaque implémentation séparément avec AddSingleton/Scoped/Transient. Pour récupérer toutes les implémentations, injecter IEnumerable qui contiendra toutes les instances enregistrées. Si un seul Add est appelé avec GetRequiredService, seule la dernière implémentation enregistrée sera résolue. Ce pattern est utile pour les plugins, stratégies multiples ou handlers. Les implémentations sont résolues dans l'ordre d'enregistrement."}},{"@type":"Question","name":"Qu'est-ce qu'une captive dependency et pourquoi est-ce un problème ?","acceptedAnswer":{"@type":"Answer","text":"Une captive dependency se produit quand un service avec un lifetime long (Singleton) dépend d'un service avec un lifetime plus court (Scoped ou Transient). Le service Scoped devient captif du Singleton et vit aussi longtemps que le Singleton, perdant son comportement de lifetime. Cela cause des bugs subtils comme réutiliser un DbContext entre plusieurs requêtes HTTP, entraînant des erreurs de concurrence. Le conteneur DI de .NET peut détecter ce problème au démarrage avec ValidateOnBuild et ValidateScopes activés."}},{"@type":"Question","name":"Comment utiliser IServiceScopeFactory dans un BackgroundService ?","acceptedAnswer":{"@type":"Answer","text":"Dans un BackgroundService (Singleton), injecter IServiceScopeFactory au lieu de services Scoped directement pour éviter les captive dependencies. Créer un scope avec CreateScope() dans ExecuteAsync, puis résoudre les services Scoped depuis scope.ServiceProvider. Disposer le scope après utilisation (using statement). Ce pattern garantit que chaque itération du background worker obtient des instances fraîches des services Scoped comme DbContext. Sans scope, les services Scoped deviendraient captifs du Singleton."}},{"@type":"Question","name":"Qu'est-ce que l'Options Pattern et comment l'utiliser avec DI ?","acceptedAnswer":{"@type":"Answer","text":"L'Options Pattern permet d'injecter des configurations fortement typées depuis appsettings.json. Configurer avec services.Configure(configuration.GetSection(\"MySection\")), puis injecter IOptions dans les services pour accéder à la configuration via la propriété Value. Utiliser IOptionsSnapshot pour des valeurs rafraîchies à chaque scope (requête HTTP), ou IOptionsMonitor pour des changements en temps réel. Ce pattern offre validation automatique, typage fort et testabilité améliorée comparé à IConfiguration directement."}},{"@type":"Question","name":"Pourquoi le Service Locator est-il considéré comme un anti-pattern ?","acceptedAnswer":{"@type":"Answer","text":"Le Service Locator (injecter IServiceProvider pour résoudre des services) masque les dépendances réelles d'une classe, rendant le code difficile à tester et à comprendre. Les dépendances ne sont pas visibles dans le constructeur, violant le principe d'inversion de dépendances. Cela peut causer des exceptions runtime si un service n'est pas enregistré, alors que l'injection par constructeur échoue au démarrage. Utiliser l'injection par constructeur explicite pour documenter clairement les dépendances. Le Service Locator est acceptable uniquement dans des cas spécifiques comme les factories ou plugins."}},{"@type":"Question","name":"Quelle est la différence entre constructor injection et property injection ?","acceptedAnswer":{"@type":"Answer","text":"Constructor injection passe les dépendances via le constructeur, garantissant que l'objet est toujours dans un état valide avec toutes ses dépendances obligatoires. Property injection définit les dépendances via des propriétés publiques après l'instanciation, utilisée pour des dépendances optionnelles. Le conteneur DI .NET standard ne supporte pas nativement la property injection (contrairement à d'autres frameworks). Constructor injection est fortement recommandée car elle rend les dépendances explicites, améliore la testabilité et garantit l'immutabilité."}},{"@type":"Question","name":"Comment créer et utiliser un scope manuellement pour résoudre des services Scoped ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser IServiceScopeFactory.CreateScope() pour créer un nouveau scope, puis résoudre les services depuis scope.ServiceProvider.GetRequiredService. Disposer le scope après utilisation avec using statement pour libérer les ressources et appeler Dispose sur les services Scoped. Ce pattern est utile dans les BackgroundService, tests unitaires ou tout code qui s'exécute en dehors du pipeline HTTP. Le scope garantit que les services Scoped ont un cycle de vie isolé et sont correctement disposés."}},{"@type":"Question","name":"Que se passe-t-il avec les services IDisposable enregistrés dans le conteneur DI ?","acceptedAnswer":{"@type":"Answer","text":"Le conteneur DI track automatiquement tous les services IDisposable et appelle Dispose() quand le scope ou le service provider est disposé. Les Singleton sont disposés quand l'application s'arrête, les Scoped à la fin de la requête HTTP, et les Transient à la fin du scope qui les a créés. Éviter de créer des services IDisposable Transient car ils restent en mémoire jusqu'à la fin du scope racine. Le conteneur garantit la disposal dans l'ordre inverse de la création pour respecter les dépendances."}},{"@type":"Question","name":"Comment enregistrer un service avec une factory method ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser la surcharge de AddSingleton/Scoped/Transient acceptant un Func comme factory. La factory reçoit le IServiceProvider pour résoudre des dépendances et retourne l'instance du service. Utile pour une logique de création complexe, initialisation conditionnelle ou résolution de dépendances multiples. La factory est appelée selon le lifetime configuré. Exemple: services.AddScoped(sp => new MyService(sp.GetRequiredService(), \"config\")). Ce pattern offre un contrôle total sur l'instanciation."}},{"@type":"Question","name":"Que se passe-t-il si un service Singleton dépend d'un service Transient ?","acceptedAnswer":{"@type":"Answer","text":"Le service Transient devient captif du Singleton et vit aussi longtemps que le Singleton au lieu d'être recréé à chaque injection. Cela viole le comportement attendu du Transient et peut causer des bugs si le Transient maintient un état. Le conteneur DI peut détecter cette violation avec ValidateOnBuild et ValidateScopes activés au démarrage, levant une exception. Pour corriger, utiliser IServiceScopeFactory dans le Singleton pour créer un scope et résoudre le Transient quand nécessaire. Éviter absolument d'injecter des services avec lifetime plus court dans des services avec lifetime plus long."}},{"@type":"Question","name":"Comment utiliser ServiceDescriptor pour créer une registration custom ?","acceptedAnswer":{"@type":"Answer","text":"ServiceDescriptor est la classe bas-niveau pour décrire un service enregistré. Créer un descriptor avec new ServiceDescriptor(serviceType, implementationType, lifetime) ou avec une factory. Ajouter le descriptor avec services.Add(descriptor). Utile pour des registrations conditionnelles, dynamiques ou basées sur des métadonnées. Les méthodes AddSingleton/Scoped/Transient utilisent ServiceDescriptor en interne. Exemple: var descriptor = new ServiceDescriptor(typeof(IService), sp => CreateService(sp), ServiceLifetime.Scoped). Ce pattern offre plus de flexibilité que les méthodes d'extension standard."}},{"@type":"Question","name":"Qu'est-ce que le Service Provider Root et pourquoi est-ce important ?","acceptedAnswer":{"@type":"Answer","text":"Le Service Provider Root est le conteneur racine créé par BuildServiceProvider() qui vit pour toute la durée de l'application. Il contient tous les services Singleton et track les services IDisposable Transient créés dans le scope racine, causant des memory leaks si beaucoup de Transient IDisposable sont résolus directement depuis le root. Dans ASP.NET Core, chaque requête crée un scope enfant pour isoler les services Scoped. Éviter de résoudre des services depuis le root provider sauf au démarrage de l'application. Utiliser des scopes pour gérer le cycle de vie correctement."}},{"@type":"Question","name":"Comment tester du code qui utilise la Dependency Injection ?","acceptedAnswer":{"@type":"Answer","text":"Créer un ServiceCollection de test, enregistrer les dépendances réelles ou des mocks (Moq, NSubstitute), construire le ServiceProvider et résoudre le service à tester. Pour les tests unitaires, injecter directement des mocks dans le constructeur sans utiliser le conteneur DI. Pour les tests d'intégration ASP.NET Core, utiliser WebApplicationFactory qui fournit un conteneur DI pré-configuré avec possibilité de remplacer des services via ConfigureTestServices. L'injection par constructeur facilite les tests car les dépendances sont explicites et facilement remplaçables."}},{"@type":"Question","name":"Quelle est la différence entre TryAdd et Add pour enregistrer un service ?","acceptedAnswer":{"@type":"Answer","text":"TryAddSingleton/Scoped/Transient enregistre le service uniquement s'il n'existe pas déjà pour le même type de service. Si un service est déjà enregistré, TryAdd ne fait rien. Add enregistre toujours le service, créant potentiellement plusieurs registrations pour la même interface. TryAdd est utile pour des registrations par défaut qui peuvent être overridées, ou pour éviter des doublons dans des modules réutilisables. Avec GetRequiredService, seule la dernière registration est résolue. Avec IEnumerable, toutes les registrations sont retournées."}},{"@type":"Question","name":"Comment remplacer un service déjà enregistré dans le conteneur DI ?","acceptedAnswer":{"@type":"Answer","text":"Utiliser services.Replace(ServiceDescriptor.Scoped()) pour remplacer la registration existante. La méthode Replace recherche et remplace le premier service du type spécifié. Alternativement, retirer l'ancienne registration avec services.RemoveAll() puis ajouter la nouvelle avec Add. En ASP.NET Core, ConfigureTestServices dans WebApplicationFactory remplace automatiquement les services pour les tests. Le remplacement est utile pour substituer des implémentations en tests ou configurer des comportements différents selon l'environnement."}},{"@type":"Question","name":"Qu'est-ce que Keyed Services introduit dans .NET 8 ?","acceptedAnswer":{"@type":"Answer","text":"Keyed Services permet d'enregistrer plusieurs implémentations d'une interface avec des clés distinctes. Enregistrer avec services.AddKeyedSingleton(\"key\") et résoudre avec [FromKeyedServices(\"key\")] IService ou GetKeyedService(\"key\"). Utile pour des stratégies multiples (paiement par carte, PayPal), clients HTTP nommés ou configurations par environnement. Avant .NET 8, il fallait utiliser des factories ou des wrappers. Keyed Services simplifie ce pattern courant en offrant un support natif du conteneur DI."}},{"@type":"Question","name":"Comment gérer les circular dependencies dans le système de DI ?","acceptedAnswer":{"@type":"Answer","text":"Les circular dependencies (ServiceA dépend de ServiceB qui dépend de ServiceA) causent une exception au runtime lors de la résolution. Solutions: refactoriser pour éliminer la circularité (extraire la logique commune dans un troisième service), utiliser une interface ou factory pour lazy loading, ou injecter IServiceProvider pour résoudre manuellement une dépendance. La meilleure solution est toujours de refactoriser l'architecture pour éviter les dépendances circulaires. Le conteneur DI .NET détecte les circular dependencies simples mais pas toujours les chaînes complexes."}}]}