Injeção de Dependência em C#: O Guia Prático para Código Limpo e Testável no .NET
Neste guia, você entenderá o problema que a DI resolve, como ela funciona no ecossistema .NET e, crucialmente, como os ciclos de vida das dependências podem afetar a performance e a estabilidade da sua aplicação.
1. O Problema: Acoplamento e Código Rígido
Para entender o valor da DI, precisamos primeiro olhar para o problema do acoplamento.
Imagine uma classe chamada ProcessadorDePedidos que precisa de um serviço para salvar dados no banco de dados (RepositorioDeDados):
// Exemplo de código ALTAMENTE ACOPLADO
public class ProcessadorDePedidos
{
private readonly RepositorioDeDados _repositorio;
public ProcessadorDePedidos()
{
// ❌ A classe 'ProcessadorDePedidos' está DIRETAMENTE ligada a 'RepositorioDeDados'.
_repositorio = new RepositorioDeDados();
}
public void Processar(Pedido pedido)
{
// ... lógica de negócio ...
_repositorio.Salvar(pedido);
}
}
Por que isso é um problema?
Impossível de Testar: Ao testar
ProcessadorDePedidos, você sempre estará testando oRepositorioDeDadosreal, que pode exigir uma conexão ativa com o banco. Isso inviabiliza testes de unidade rápidos e isolados.Rígido à Mudança: Se você decidir trocar a implementação de um banco SQL para um NoSQL, terá que modificar todo o código onde
new RepositorioDeDados()foi usado.Difícil de Reutilizar: A classe está presa àquela implementação específica, limitando sua reutilização em outros contextos.
2. A Solução: Inversão de Controle (IoC) e DI
A solução para o acoplamento é seguir o Princípio da Inversão de Dependência (DIP), um dos princípios SOLID: dependa de abstrações, não de implementações.
O Primeiro Passo: Abstrações (Interfaces)
Em vez de depender da classe concreta RepositorioDeDados, dependemos de uma interface (IRepositorioDeDados):
public interface IRepositorioDeDados
{
void Salvar(Pedido pedido);
}
public class RepositorioDeDados : IRepositorioDeDados // Implementação Concreta
{
public void Salvar(Pedido pedido) { /* ... lógica de salvar no banco ... */ }
}
O Segundo Passo: Injeção pelo Construtor (DI)
Agora, o ProcessadorDePedidos não cria o repositório, ele o recebe pelo construtor. Isso é a Injeção de Dependência:
// Exemplo com Injeção de Dependência (Baixo Acoplamento)
public class ProcessadorDePedidos
{
// ✅ Depende da ABSTRAÇÃO (Interface), não da IMPLEMENTAÇÃO.
private readonly IRepositorioDeDados _repositorio;
// O objeto é "Injetado" aqui. Quem injeta é o Container DI.
public ProcessadorDePedidos(IRepositorioDeDados repositorio)
{
_repositorio = repositorio;
}
public void Processar(Pedido pedido)
{
// ...
_repositorio.Salvar(pedido);
}
}
🔑 Conclusão: A Injeção de Dependência apenas move a responsabilidade de criar a dependência para fora da classe. O Container DI (que no .NET é o
IServiceCollection) assume essa responsabilidade, gerenciando o ciclo de vida e a criação das instâncias.
3. Os Ciclos de Vida (Lifetimes) no .NET
No .NET, você não apenas registra as dependências, mas também define por quanto tempo o Container DI deve manter viva a instância dessa dependência. Escolher o Ciclo de Vida correto é crucial para a performance, escalabilidade e, principalmente, para evitar bugs.
O .NET oferece três principais ciclos de vida:
| Ciclo de Vida | Método de Registro | Comportamento | Uso Típico |
| Transient | AddTransient<TInterface, TImplementation>() | Uma nova instância é criada a cada vez que o serviço é solicitado/injetado. | Serviços leves e sem estado (ex: Helpers, Mappers). |
| Scoped | AddScoped<TInterface, TImplementation>() | Uma única instância é criada por Escopo (geralmente, uma requisição HTTP). | Serviços que precisam manter o estado durante uma única transação, como um Unit of Work ou Contexto de Banco de Dados (DbContext). |
| Singleton | AddSingleton<TInterface, TImplementation>() | Uma única instância é criada na primeira vez que é solicitada e é reutilizada durante toda a vida da aplicação. | Serviços de configuração, caches em memória, serviços de logging globais. |
Quando Usar Cada Um?
Singleton: Ideal para recursos que consomem muita memória ou tempo para inicializar e que não devem ter estado que mude com o usuário (são thread-safe). Cuidado: Se um
Singletontiver estado mutável, diferentes usuários podem interferir nos dados uns dos outros!Scoped: Se sua aplicação é uma API ou um aplicativo web, o
Scopedé o mais comum. Garante que todos os componentes de uma única requisição (ex: Controller, Service, Repository) usem a mesma instância doDbContext, por exemplo. Isso é fundamental para que as transações de banco de dados funcionem corretamente.Transient: Use para serviços que executam operações rápidas e não mantêm nenhuma informação após a conclusão do método.
4. Configurando a Injeção de Dependência no .NET
No ASP.NET Core e no .NET moderno, a configuração da DI acontece no arquivo principal da aplicação, geralmente o Program.cs, através da interface IServiceCollection.
Exemplo de Configuração
Supondo que temos as interfaces e implementações: IProdutoService -> ProdutoService, IAuthService -> AuthService, e AppCache (uma classe de cache).
var builder = WebApplication.CreateBuilder(args);
// 1. Transient: Um novo serviço a cada uso
builder.Services.AddTransient<IProdutoService, ProdutoService>();
// 2. Scoped: Um novo DbContext para cada requisição HTTP
builder.Services.AddScoped<IRepositorio, RepositorioDeDados>();
// (Se fosse um DbContext real, seria AddDbContext)
// 3. Singleton: A mesma instância para toda a aplicação
builder.Services.AddSingleton<AppCache>();
var app = builder.Build();
// ... restante da configuração e endpoints ...
Depois desse registro, o Container DI sabe que, sempre que uma classe solicitar (via construtor) uma instância de IRepositorio, ele deve fornecer a implementação RepositorioDeDados com o ciclo de vida Scoped.
5. O Erro Crítico: Captura de Dependência (Captive Dependency)
Um dos erros mais comuns e perigosos ao usar DI é a Captura de Dependência (também conhecido como Captive Dependency). Isso ocorre quando um serviço de ciclo de vida mais longo tenta injetar um serviço de ciclo de vida mais curto.
| Injetor (Longer Lifetime) | Dependência Injetada (Shorter Lifetime) | Resultado |
| Singleton | Scoped ou Transient | Erro: O serviço Singleton "congela" a primeira instância do serviço mais curto. O serviço Scoped ou Transient passa a se comportar como um Singleton, violando seu ciclo de vida. |
Exemplo Prático e Perigoso:
Você registra seu
DbContextcomo Scoped (correto).Você registra um serviço de Cache Global como Singleton.
O serviço Cache Global injeta o
DbContextem seu construtor.
O resultado é que o DbContext (que deveria viver apenas pela requisição atual) agora vive pelo tempo de vida da aplicação inteira, podendo causar problemas sérios de concorrência, vazamento de recursos e erros de estado entre diferentes requisições de usuários.
Como Evitar?
Sempre inicie a injeção do ciclo de vida mais curto para o mais longo:
Um serviço Transient pode injetar um Singleton, mas um serviço Singleton nunca deve injetar um Scoped ou Transient.
6. O Benefício Imediato: Testabilidade
O maior benefício da Injeção de Dependência é a testabilidade do seu código.
Ao depender de interfaces, você pode facilmente trocar as implementações reais por Mocks (objetos de teste simulados) durante o teste de unidade.
Exemplo de Teste
Para testar o ProcessadorDePedidos, você não precisa de um banco de dados. Você usa um Mock que simula o comportamento do IRepositorioDeDados:
// Usando Moq (uma biblioteca popular de mocking)
[Fact]
public void Processar_DeveChamarSalvarNoRepositorio()
{
// Arrange: Criar um mock da dependência (IRepositorioDeDados)
var mockRepositorio = new Mock<IRepositorioDeDados>();
// Configurar o comportamento do mock (ex: não fazer nada)
// mockRepositorio.Setup(r => r.Salvar(It.IsAny<Pedido>())).Verifiable();
// Injetar o mock na classe que estamos testando
var processador = new ProcessadorDePedidos(mockRepositorio.Object);
var pedido = new Pedido { Id = 1 };
// Act
processador.Processar(pedido);
// Assert: Verificar se o método "Salvar" foi chamado EXATAMENTE UMA VEZ
mockRepositorio.Verify(r => r.Salvar(pedido), Times.Once);
}
Com a DI, você garante que sua lógica de negócio (ProcessadorDePedidos) é testada de forma isolada e confiável, sem depender de fatores externos.
A Injeção de Dependência é a ferramenta fundamental do .NET para criar software flexível, escalável e facilmente mantido por equipes grandes. Invista tempo para dominar o conceito e, principalmente, os ciclos de vida, e você elevará drasticamente a qualidade de seus projetos C#.
Exemplos de Código para Prática
Para consolidar o aprendizado, veja exemplos práticos de como declarar e consumir os diferentes ciclos de vida da Injeção de Dependência em C# e .NET.
Exemplo 1: Comparando os Ciclos de Vida em uma Requisição (Scoped vs. Transient vs. Singleton)
Este exemplo mostra como a injeção acontece na prática. Imagine um serviço que apenas gera um ID para rastreamento.
1. Definição das Classes
// 1. A Abstração (Interface)
public interface IOpService
{
Guid OperationId { get; }
}
// 2. A Implementação (Usa um GUID para simular um ID de instância)
public class OpService : IOpService
{
public Guid OperationId { get; } = Guid.NewGuid();
}
// 3. O Consumidor (Injeta e usa dois serviços diferentes)
// Nota: Em um projeto real, esta seria uma Controller ou Minimal API Endpoint
public class Consumidor
{
public IOpService TransientService { get; }
public IOpService ScopedService { get; }
public IOpService SingletonService { get; }
public Consumidor(
IOpService transientService, // Injeção de Dependência Transient
IOpService scopedService, // Injeção de Dependência Scoped
IOpService singletonService // Injeção de Dependência Singleton
)
{
TransientService = transientService;
ScopedService = scopedService;
SingletonService = singletonService;
}
}
2. Configuração no Program.cs
A chave está em como registramos cada serviço no Container DI:
var builder = WebApplication.CreateBuilder(args);
// Configuração dos ciclos de vida:
builder.Services.AddTransient<IOpService, OpService>(); // Novo a cada injeção
builder.Services.AddScoped<IOpService, OpService>(); // Um por requisição (Escopo)
builder.Services.AddSingleton<IOpService, OpService>(); // Único para a Aplicação
// O Consumidor também é Scoped (um por requisição)
builder.Services.AddScoped<Consumidor>();
3. Resultado Esperado em Duas Requisições
| Serviço | Requisição 1 (Escopo 1) | Requisição 2 (Escopo 2) | O que aconteceu? |
| Transient | 8b5f-A111 | 4c1e-B222 | Diferentes em cada injeção. |
| Scoped | d30a-C333 | e97b-D444 | Diferentes entre Escopos, mas o mesmo dentro do mesmo escopo. |
| Singleton | f1a8-E555 | f1a8-E555 | O Mesmo ID em toda a aplicação. |
Exemplo 2: O Padrão de Injeção de Dependência mais Usado: DbContext
Para qualquer aplicação que usa Entity Framework Core, o ciclo de vida Scoped é o padrão para o contexto do banco de dados (DbContext).
// 1. Definição do Repositório (Depende do Contexto)
public interface IUsuarioRepository
{
Usuario Get(int id);
}
public class UsuarioRepository : IUsuarioRepository
{
// Injetamos o DbContext (que é Scoped)
private readonly ApplicationDbContext _context;
public UsuarioRepository(ApplicationDbContext context)
{
_context = context;
}
public Usuario Get(int id)
{
return _context.Usuarios.Find(id);
}
}
// 2. Configuração no Program.cs
// Esta é a forma padrão de configurar o EF Core, garantindo o Scoped.
builder.Services.AddDbContext<ApplicationDbContext>(options =>
{
options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection"));
}, ServiceLifetime.Scoped); // <-- O Scoped é o padrão aqui
// 3. Registro do Repositório (Também Scoped para acompanhar o DbContext)
builder.Services.AddScoped<IUsuarioRepository, UsuarioRepository>();
Resultado: Durante uma única requisição (Escopo), todos os serviços, repositórios e o DbContext compartilham a mesma instância. Isso garante que todas as operações de banco de dados (ler, atualizar, salvar) façam parte de uma única unidade de trabalho lógica.
Exemplo 3: Injeção de Dependência no Consumidor (Serviços)
Este exemplo demonstra a cadeia de injeção: um serviço injetando outro, que injeta outro, mantendo o baixo acoplamento em toda a pilha da aplicação.
// 1. Serviço de Cache (Singleton para guardar dados globalmente)
public interface ICacheService
{
string GetData(string key);
}
public class MemoryCacheService : ICacheService
{
private readonly Guid _id = Guid.NewGuid(); // Singleton ID
public string GetData(string key) => $"Dados do Cache {_id}";
}
// 2. Serviço de Vendas (Scoped - vive por requisição)
public interface IVendasService
{
string ExecutarVenda();
}
public class VendasService : IVendasService
{
// ✅ Injeta o Singleton sem problemas! (Singleton é o ciclo de vida mais longo)
private readonly ICacheService _cache;
public VendasService(ICacheService cache)
{
_cache = cache;
}
public string ExecutarVenda() => $"Venda executada com: {_cache.GetData("Precos")}";
}
Configuração no Program.cs
// 1. O Cache (Singleton)
builder.Services.AddSingleton<ICacheService, MemoryCacheService>();
// 2. O Serviço de Vendas (Scoped - Mais Comum para Lógica de Negócio)
builder.Services.AddScoped<IVendasService, VendasService>();
Resultado: O Container DI garante que o VendasService (que é criado a cada requisição) receba a única e mesma instância do MemoryCacheService durante toda a vida da aplicação.
Conclusão: A DI como Padrão de Excelência
A Injeção de Dependência pode parecer, à primeira vista, apenas uma forma diferente de instanciar objetos. No entanto, ela é a base de um software moderno, performático e, acima de tudo, sustentável.
Ao adotar a DI, você está ativamente aplicando o princípio da Inversão de Dependência (DIP), garantindo que seu código dependa de abstrações (interface) e não de implementações concretas.
Lembre-se dos pilares da DI:
Testabilidade: Ao injetar interfaces, você pode facilmente isolar e testar qualquer componente do seu sistema usando mocks.
Flexibilidade: Seus serviços se tornam plugáveis. Trocar um banco de dados, um sistema de cache ou um serviço de terceiros é uma questão de mudar uma linha de registro no
Program.cs, não de reescrever lógica interna.Performance e Escopo: Dominar os ciclos de vida (Transient, Scoped, Singleton) permite que você gerencie o uso de memória e a concorrência de forma eficiente, evitando bugs sutis e perigosos como a Captura de Dependência.
A Injeção de Dependência não é opcional no ecossistema .NET Core; é a melhor prática. Ao internalizar esse padrão, você não apenas escreve código que funciona, mas código que é confiável, fácil de manter e preparado para o futuro.
Agora que você conhece a teoria e a prática, comece a aplicar esses conceitos em seu próximo projeto e experimente o poder do código limpo!
Comentários
Postar um comentário