Como funciona a injeção de dependência no .NET?

Question

Accepted Answer

**Dependency Injection (DI)** é integrada ao .NET moderno — o framework inclui um contêiner de DI que constrói automaticamente classes e **injeta suas dependências**. Você registra serviços (mapeando interfaces para implementações) e o contêiner as resolve, permitindo código fracamente acoplado e testável. É fundamental para ASP.NET Core. ## Registrando serviços ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Você registra cada mapeamento de serviço de uma **interface para uma implementação** com um tempo de vida. Então qualquer coisa que dependa da interface recebe a implementação registrada. ## Injeção de construtor (o padrão padrão) ```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 ``` Dependências são declaradas como parâmetros de construtor (tipados como interfaces); o contêiner constrói a classe e injeta as implementações registradas, resolvendo automaticamente todo o gráfico de dependência. ## Tempos de vida de serviço (importante escolher corretamente) ```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. ``` ## Os benefícios: acoplamento solto e testabilidade ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Por que isso importa A injeção de dependência é fundamental para .NET moderno — é **integrada ao framework** e é a base do ASP.NET Core, então compreendê-la é essencial para qualquer desenvolvimento moderno de aplicação C#. O contêiner de DI integrado do framework constrói automaticamente classes e injeta suas dependências (resolvendo o gráfico completo de dependência), então você registra serviços e deixa o contêiner conectar tudo junto em vez de instanciar manualmente as dependências. Os benefícios principais são significativos e centrais para por que DI é enfatizada: **acoplamento solto** (depender de interfaces em vez de classes concretas, então implementações podem ser trocadas) e especialmente **testabilidade** (injetar implementações mock em testes em vez de dependências reais como bancos de dados ou serviços de email — tornando testes unitários completos práticos). Compreender como registrar serviços (mapeando interfaces para implementações), injeção de construtor (o padrão padrão), e — importante — os **tempos de vida de serviço** (`Singleton`, `Scoped`, `Transient`) é essencial: escolher o tempo de vida errado causa bugs sutis e difíceis de depurar (ex: um singleton mantendo um `DbContext` com escopo, ou problemas de segurança de thread com singletons compartilhados), então entender quando cada tempo de vida se aplica (Scoped por requisição para coisas como DbContext, Singleton para serviços compartilhados sem estado, Transient para leves) é crítico. Com DI integrada ao .NET, sendo a base da arquitetura do ASP.NET Core, e sendo a chave para escrever código fracamente acoplado e testável, dominar isso — o contêiner, injeção de construtor, design baseado em interface, e especialmente os tempos de vida de serviço — é conhecimento senior importante e frequentemente aplicado para construir aplicações C# modernas mantíveis e testáveis, e é um tópico comum em entrevistas.