DEV Community: Otavio Augusto

Inversion of Control (IoC): o conceito por trás do código desacoplado

Otavio Augusto — Tue, 16 Jun 2026 12:28:18 +0000

Quando começamos a desenvolver software, é muito comum criarmos nossas dependências diretamente dentro das classes.

Algo parecido com isso:

public class UserService
{
    public void Register()
    {
        var emailService = new EmailService();

        emailService.Send("teste@email.com");
    }
}

Funciona.

Mas existe um problema escondido nesse código.

O UserService está assumindo uma responsabilidade que não deveria ser dele: criar suas próprias dependências.

E é justamente aqui que entra um conceito extremamente importante no desenvolvimento de software: Inversion of Control (IoC).

O que é Inversion of Control?

Antes de falar sobre ASP.NET Core ou Dependency Injection, precisamos entender o conceito.

A tradução literal é:

Inversão de Controle

Mas inversão do quê?

Da responsabilidade de criar e gerenciar objetos.

Sem IoC, a própria classe controla tudo.

UserService
    ↓
Cria EmailService

Com IoC, esse controle é transferido para outro componente.

UserService
    ↓
Recebe EmailService

A classe deixa de criar suas dependências e passa apenas a utilizá-las.

O problema de criar dependências manualmente

Vamos analisar novamente este código:

public class UserService
{
    public void Register()
    {
        var emailService = new EmailService();

        emailService.Send("teste@email.com");
    }
}

O que acontece se amanhã você quiser trocar o serviço de e-mail?

Talvez usar SendGrid.

Ou AWS SES.

Ou criar uma implementação para testes.

Será necessário alterar a própria classe.

Isso gera um problema chamado alto acoplamento.

Ou seja:

Mais difícil de testar
Mais difícil de manter
Mais difícil de evoluir

Como o IoC resolve esse problema

Agora imagine o seguinte código:

public class UserService
{
    private readonly IEmailService _emailService;

    public UserService(IEmailService emailService)
    {
        _emailService = emailService;
    }

    public void Register()
    {
        _emailService.Send("teste@email.com");
    }
}

Observe que o UserService não cria mais nada.

Ele apenas declara o que precisa para funcionar.

IEmailService

A responsabilidade de criar a dependência foi removida da classe.

O controle foi invertido.

Visualmente, a diferença é esta:

Uma analogia simples

Imagine que você trabalha em um escritório.

Sem IoC:

Você precisa comprar seu computador, instalar tudo, configurar internet e preparar seu ambiente de trabalho.

Com IoC:

Quando você chega, tudo já está pronto.

Você apenas utiliza os recursos necessários para trabalhar.

Foi exatamente isso que aconteceu com a classe.

Ela não se preocupa mais em criar suas dependências.

Ela apenas utiliza aquilo que foi fornecido para ela.

Quais são os benefícios?

Menor acoplamento

As classes passam a depender de contratos, não de implementações concretas.

Facilidade para testes

Você pode substituir implementações reais por mocks ou fakes.

Maior flexibilidade

Trocar uma implementação deixa de exigir alterações em toda a aplicação.

Código mais organizado

Cada classe passa a ter responsabilidades mais bem definidas.

IoC e Dependency Injection são a mesma coisa?

Não.

Essa é uma das maiores confusões entre desenvolvedores iniciantes.

IoC é o conceito.

Dependency Injection é uma das formas de implementar esse conceito.

Pense assim:

IoC = O conceito
DI = Uma implementação desse conceito

Primeiro entendemos a inversão do controle.

Depois utilizamos mecanismos para colocá-la em prática.

Resumo

Sem IoC:

Classe
    ↓
Cria dependências

Com IoC:

Classe
    ↓
Recebe dependências

Em outras palavras:

A classe deixa de se preocupar com como obter suas dependências e passa a focar apenas em executar sua responsabilidade.

Esse conceito é a base de praticamente todo o ecossistema moderno do ASP.NET Core.

E no próximo artigo vamos entender como o framework implementa essa inversão através da Dependency Injection.

Singleton vs Scoped vs Transient: Entenda os Lifetimes da Injeção de Dependência

Otavio Augusto — Thu, 11 Jun 2026 04:29:42 +0000

Quando começamos a trabalhar com ASP.NET Core, uma das primeiras coisas que aprendemos é a Injeção de Dependência (Dependency Injection).

Mas existe uma dúvida que acompanha muitos desenvolvedores por anos:

Quando devo usar Singleton, Scoped ou Transient?

Se você já ficou em dúvida sobre qual Lifetime utilizar ou já recebeu erros estranhos envolvendo DbContext, este artigo é para você.

Vamos entender esses conceitos de uma forma simples e prática.

Antes de tudo: o que é um Lifetime?

Imagine que sua aplicação é um hotel.

Os serviços registrados no container de Injeção de Dependência são hóspedes.

O Lifetime define:

Quanto tempo esse hóspede ficará hospedado antes de ir embora.

Dependendo da configuração escolhida, um objeto poderá:

Existir durante toda a aplicação
Existir apenas durante uma requisição
Ser recriado sempre que solicitado

É exatamente isso que Singleton, Scoped e Transient fazem.

Singleton

🏨 Analogia: O gerente do hotel

Imagine o gerente do hotel.

Existe apenas um.

Não importa quantos hóspedes cheguem ou quantos funcionários precisem de ajuda.

Todos falam com a mesma pessoa.

Request 1
     \
Request 2 ---> Gerente Único
     /
Request 3

O que acontece na aplicação?

O ASP.NET Core cria apenas uma instância e a reutiliza durante toda a vida da aplicação.

builder.Services.AddSingleton<EmailService>();

Request 1 -> Instância A
Request 2 -> Instância A
Request 3 -> Instância A

Sempre a mesma instância.

Quando usar?

✅ Cache

✅ Configurações

✅ Serviços sem estado

✅ HttpClientFactory

✅ Clients reutilizáveis

⚠️ Cuidado com estado compartilhado

Imagine que você registre o seguinte serviço:

public class UserContext
{
    public string Username { get; set; }
}

E registre como Singleton:

builder.Services.AddSingleton<UserContext>();

Agora todos os usuários da aplicação compartilharão a mesma instância.

Isso significa que informações de um usuário podem sobrescrever informações de outro.

Por esse motivo, Singleton deve ser utilizado apenas quando o serviço não possui dados específicos de usuários.

Scoped

🍽️ Analogia: O garçom do restaurante

Agora imagine os garçons.

Cada mesa recebe um garçom específico.

Durante todo o atendimento, aquela mesa conversa com o mesmo garçom.

Quando a refeição termina, o atendimento acaba.

Mesa 1 -> Garçom A

Mesa 2 -> Garçom B

Mesa 3 -> Garçom C

O que acontece na aplicação?

Uma nova instância é criada para cada requisição HTTP.

builder.Services.AddScoped<UserService>();

Request 1 -> Instância A

Request 2 -> Instância B

Request 3 -> Instância C

Quando usar?

Na prática, esse é o Lifetime mais utilizado em aplicações ASP.NET Core.

✅ DbContext

✅ Repositories

✅ Services de negócio

✅ Unit Of Work

Exemplo real

O próprio Entity Framework registra o DbContext como Scoped.

builder.Services.AddDbContext<AppDbContext>();

Cada requisição recebe seu próprio contexto.

Isso evita conflitos entre usuários.

💡 Por que o DbContext é Scoped?

Imagine duas requisições simultâneas:

Request A
Request B

Se ambas compartilhassem o mesmo DbContext, poderiam ocorrer conflitos de rastreamento de entidades, concorrência e inconsistências nos dados.

Ao utilizar Scoped, cada requisição recebe sua própria instância.

Por isso o Entity Framework registra o DbContext dessa forma por padrão.

Transient

🥤 Analogia: Um copo descartável

Imagine um copo descartável.

Você pega.

Usa.

Descarta.

Precisa de outro?

Recebe um novo.

Sempre.

Uso 1 -> Copo A

Uso 2 -> Copo B

Uso 3 -> Copo C

O que acontece na aplicação?

Uma nova instância é criada toda vez que o serviço é solicitado.

builder.Services.AddTransient<LogFormatter>();

Mesmo dentro da mesma requisição:

Resolução 1 -> Instância A

Resolução 2 -> Instância B

Resolução 3 -> Instância C

Quando usar?

✅ Formatadores

✅ Conversores

✅ Geradores de PDF

✅ Geradores de Token

✅ Serviços extremamente leves

Comparativo rápido

Característica	Singleton	Scoped	Transient
Uma instância para toda aplicação	✅	❌	❌
Uma instância por request	❌	✅	❌
Nova instância sempre	❌	❌	✅
Compartilha estado	✅	Apenas na request	❌
Mais utilizado	❌	✅	❌

Aproximadamente 80% dos serviços em aplicações ASP.NET Core acabam sendo registrados como Scoped.

O erro que quase todo desenvolvedor já viu

Registrar um Singleton que depende de um Scoped.

builder.Services.AddSingleton<UserService>();
builder.Services.AddScoped<AppDbContext>();

public class UserService
{
    public UserService(AppDbContext context)
    {
    }
}

Resultado:

Cannot consume scoped service
from singleton

O motivo é simples:

O Singleton vive durante toda a aplicação.
O Scoped vive apenas durante a requisição.

O container não consegue manter uma referência válida para um objeto que será destruído antes dele.

Resumo Visual

Conclusão

Singleton, Scoped e Transient parecem apenas detalhes da Injeção de Dependência.

Mas eles impactam diretamente:

Performance
Consumo de memória
Escalabilidade
Concorrência
Segurança dos dados

Entender os Lifetimes da Injeção de Dependência vai muito além de decorar três palavras.

Eles definem como os objetos da sua aplicação vivem, são compartilhados e são descartados.

Se você estiver em dúvida:

Singleton -> Uma instância para toda aplicação

Scoped -> Uma instância por requisição

Transient -> Uma nova instância sempre

Na maioria dos projetos ASP.NET Core:

DbContext      -> Scoped
Repositories   -> Scoped
Services       -> Scoped

Cache          -> Singleton
Configurações  -> Singleton

Formatadores   -> Transient
Conversores    -> Transient
Geradores      -> Transient

Dominar esses conceitos é um dos primeiros passos para construir aplicações robustas, escaláveis e fáceis de manter.

💬 E você?

Qual Lifetime você mais utiliza nos seus projetos hoje?

Stateless vs Stateful: Entenda a diferença de uma vez por todas

Otavio Augusto — Mon, 09 Mar 2026 03:10:35 +0000

Escolher entre uma arquitetura Stateful ou Stateless é uma das decisões mais fundamentais que tomamos ao desenhar o backend de uma aplicação. Essa escolha impacta diretamente como seu sistema escala e como ele lida com a autenticação.

Neste artigo, vamos desmistificar esses conceitos com analogias simples e exemplos práticos.

1. O que é Stateful? (O estado mantido)

Vamos entender o que é o Stateful com uma analogia simples e didática. Imagine que você frequenta a mesma cafeteria todos os dias. Ao chegar lá, o atendente já sorri e diz:

"Bom dia, Otávio! Vai querer o mesmo de sempre?"

O atendente lembra de você. Ele guardou na memória dele o seu nome e que o seu pedido favorito é um café expresso duplo. Se você disser apenas "quero mais um", ele saberá exatamente o que preparar, porque existe um contexto anterior (o estado) guardado na mente dele.

Conceito: O servidor mantém uma "conversa" ativa com o usuário. Ele armazena informações sobre o cliente (a sessão) na sua própria memória (RAM) ou em um banco de dados temporário.
Exemplo Prático: Sessões clássicas em PHP, Java (HttpSession) ou ASP.NET, onde o servidor guarda os dados do usuário no lado do servidor enquanto ele estiver logado.
Prós e Contras: É intuitivo e fácil de gerenciar em aplicações pequenas (monolitos), mas é difícil de escalar horizontalmente. Se você precisar de 5 servidores rodando a mesma app, precisará de estratégias complexas (como Sticky Sessions ou Redis) para que todos "conheçam" a sessão do usuário.
Exemplo de código (.NET): No ASP.NET, usamos o objeto Session para que o servidor memorize o usuário.

// O servidor guarda o nome na Sessão (Estado mantido na RAM do servidor)
HttpContext.Session.SetString("UsuarioNome", "Otávio");

// Para recuperar, o servidor busca na própria memória:
var nome = HttpContext.Session.GetString("UsuarioNome");

2. O que é Stateless? (O estado enviado)

Agora imagine que você entra em uma cafeteria de autoatendimento. Você chega no balcão e diz: "Meu nome é Otávio e quero um café expresso". O atendente te entrega o café e esquece quem você é no segundo seguinte.

Se você quiser outro café, terá que dizer tudo de novo: "Meu nome é Otávio e quero outro café expresso". Cada interação é completa por si só. O atendente não precisa lembrar de nada; você traz toda a informação necessária em cada pedido.

Na prática (Backend):

Conceito: O servidor não guarda nada sobre o cliente entre as requisições. Toda a informação necessária para processar a tarefa deve vir na própria requisição (geralmente no Header).
Exemplo Prático: APIs REST modernas e autenticação via JWT (JSON Web Token).
Prós e Contras: Altamente escalável e ideal para microserviços, mas as requisições podem ficar levemente mais "pesadas", já que carregam os dados de autenticação (o token) em cada chamada.

// O servidor não busca na memória interna "quem é este usuário".
// Ele extrai a informação direto do Token que o cliente enviou no Header.
@GetMapping("/perfil")
public ResponseEntity<String> getPerfil(@RequestHeader("Authorization") String token) {
    // O servidor é "frio": ele não tem uma lista de usuários logados na RAM.
    // Ele apenas decodifica o JWT que o cliente enviou para saber quem é o usuário.

    if (token != null && token.startsWith("Bearer ")) {
        String jwt = token.substring(7);
        String username = jwtService.extractUsername(jwt); // Extrai o "sub" do payload do JWT

        return ResponseEntity.ok("Usuário identificado via Token: " + username);
    }

    return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
}

3. Comparativo: Stateful vs Stateless

Característica	Stateful	Stateless
Armazenamento	Servidor (Memória/RAM)	Cliente (Token/Cookie)
Escalabilidade	Difícil (Requer Sticky Sessions)	Fácil (Foco em Cloud e Microserviços)
Exemplo Real	Sessões PHP, Carrinhos antigos	APIs REST, JWT, OAuth2
Conexão	Mantém um histórico da conversa	Cada requisição é uma nova conversa

Conclusão: Qual escolher?

A regra de ouro hoje em dia para o desenvolvimento web moderno é: Dê preferência ao Stateless. Se você pretende rodar sua aplicação na nuvem (AWS, Azure, Google Cloud) ou usar Docker/Kubernetes, o modelo Stateless permite que você suba 10 ou 100 instâncias do seu serviço sem se preocupar se o usuário vai "cair" em um servidor que não conhece a sessão dele.

O Stateful ainda tem seu espaço em sistemas legados ou aplicações monolíticas muito específicas, mas o futuro (e o presente) é Stateless.

Espero que essa explicação tenha ajudado a clarear esses conceitos! Se tiver alguma dúvida ou quiser compartilhar como você utiliza isso nos seus projetos em Node.js, Java ou .NET, deixa um comentário abaixo! 🚀