Comment fonctionne l'injection de dépendances dans .NET ?

Question

Accepted Answer

**L'injection de dépendances (DI)** est intégrée dans .NET moderne — le framework inclut un conteneur DI qui construit automatiquement les classes et **injecte leurs dépendances**. Vous enregistrez des services (mappant des interfaces à des implémentations) et le conteneur les résout, permettant un code faiblement couplé et testable. C'est fondamental pour ASP.NET Core. ## Enregistrement des services ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Vous enregistrez chaque mappage de service mappant une **interface à une implémentation** avec une durée de vie. Ensuite, tout ce qui dépend de l'interface obtient l'implémentation enregistrée. ## Injection par constructeur (le modèle standard) ```csharp public class UserService { private readonly IUserRepository _repo; private readonly IEmailSender _email; // dependencies are declared in the constructor — the container INJECTS them automatically public UserService(IUserRepository repo, IEmailSender email) { _repo = repo; _email = email; } } // you never `new UserService(...)` manually — the container builds it, resolving the chain ``` Les dépendances sont déclarées comme paramètres du constructeur (typées en tant qu'interfaces) ; le conteneur construit la classe et injecte les implémentations enregistrées, en résolvant automatiquement le graphe de dépendances complet. ## Durées de vie des services (important de choisir correctement) ```text Singleton → ONE instance for the entire app lifetime (shared; must be thread-safe) Scoped → one instance PER request (the common default for web — e.g. DbContext) Transient → a NEW instance every time it's requested (lightweight, stateless services) → Choosing wrong (e.g. a singleton capturing a scoped DbContext) causes subtle bugs. ``` ## Les avantages : couplage faible et testabilité ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Pourquoi c'est important L'injection de dépendances est fondamentale pour .NET moderne — elle est **intégrée au framework** et constitue l'épine dorsale d'ASP.NET Core, donc la comprendre est essentielle pour tout développement d'application C# moderne. Le conteneur DI intégré au framework construit automatiquement les classes et injecte leurs dépendances (en résolvant le graphe de dépendances complet), vous enregistrez donc les services et laissez le conteneur interconnecter tout plutôt que d'instancier manuellement les dépendances. Les avantages principaux sont significatifs et au cœur de la raison pour laquelle la DI est mise en avant : **couplage faible** (dépendre des interfaces plutôt que des classes concrètes, afin que les implémentations puissent être échangées) et surtout **testabilité** (injecter des implémentations fictives dans les tests au lieu de vraies dépendances comme les bases de données ou les services d'e-mail — rendant les tests unitaires approfondis pratiques). Comprendre comment enregistrer les services (mapper des interfaces à des implémentations), l'injection par constructeur (le modèle standard), et — important — les **durées de vie des services** (`Singleton`, `Scoped`, `Transient`) est essentiel : choisir la mauvaise durée de vie cause des bugs subtils et difficiles à déboguer (par exemple, un singleton contenant un `DbContext` scoped, ou des problèmes de thread-safety avec des singletons partagés), donc comprendre quand chaque durée de vie s'applique (Scoped par requête pour des choses comme DbContext, Singleton pour les services partagés sans état, Transient pour les services légers) est critique. Comme la DI est intégrée à .NET, sous-tend l'architecture d'ASP.NET Core, et est la clé pour écrire du code faiblement couplé et testable, la maîtriser — le conteneur, l'injection par constructeur, la conception basée sur les interfaces, et surtout les durées de vie des services — est une connaissance senior importante et fréquemment appliquée pour construire des applications C# modernes maintenables et testables, et est un sujet d'entretien courant.