How does dependency injection work in .NET?

Question

Accepted Answer

**Dependency Injection (DI)** is built into modern .NET — the framework includes a DI container that automatically constructs classes and **injects their dependencies**. You register services (mapping interfaces to implementations) and the container resolves them, enabling loosely-coupled, testable code. It's foundational to ASP.NET Core. ## Registering services ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` You register each service mapping an **interface to an implementation** with a lifetime. Then anything depending on the interface gets the registered implementation. ## Constructor injection (the standard pattern) ```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 ``` Dependencies are declared as constructor parameters (typed as interfaces); the container constructs the class and injects the registered implementations, resolving the whole dependency graph automatically. ## Service lifetimes (important to choose correctly) ```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. ``` ## The benefits: loose coupling and testability ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Why it matters Dependency injection is foundational to modern .NET — it's **built into the framework** and is the backbone of ASP.NET Core, so understanding it is essential for any modern C# application development. The framework's built-in DI container automatically constructs classes and injects their dependencies (resolving the whole dependency graph), so you register services and let the container wire everything together rather than manually instantiating dependencies. The core benefits are significant and central to why DI is emphasized: **loose coupling** (depending on interfaces rather than concrete classes, so implementations can be swapped) and especially **testability** (injecting mock implementations in tests instead of real dependencies like databases or email services — making thorough unit testing practical). Understanding how to register services (mapping interfaces to implementations), constructor injection (the standard pattern), and — importantly — the **service lifetimes** (`Singleton`, `Scoped`, `Transient`) is essential: choosing the wrong lifetime causes subtle, hard-to-debug bugs (e.g. a singleton holding a scoped `DbContext`, or thread-safety issues with shared singletons), so understanding when each lifetime applies (Scoped per-request for things like DbContext, Singleton for shared stateless services, Transient for lightweight ones) is critical. Since DI is built into .NET, underpins ASP.NET Core's architecture, and is the key to writing loosely-coupled, testable code, mastering it — the container, constructor injection, interface-based design, and especially the service lifetimes — is important, frequently-applied senior knowledge for building maintainable, testable modern C# applications, and a common interview topic.