AddTransient, AddScoped e AddSingleton: diferenças em C# com exemplos práticos

AddTransient, AddScoped e AddSingleton: Como não se confundir com os ciclos de vida dos serviços em C#

Você já se pegou pensando: "Por que meu serviço está mantendo dados entre requisições, mesmo eu não tendo pedido isso?" Ou o contrário — "Por que toda vez um novo objeto é criado e eu perco o estado?"

Bem-vindo ao mundo da injeção de dependência (Dependency Injection, DI) no ASP.NET Core! Este é um dos tópicos mais poderosos e, ao mesmo tempo, mais confusos para iniciantes. Hoje vamos desvendar os três pilares que sustentam o gerenciamento de objetos em C#: AddTransient, AddScoped e AddSingleton.

Ao final deste artigo, você não só entenderá a diferença, mas também conseguirá responder com confiança a essa pergunta em uma entrevista de emprego (sim, eles adoram perguntar isso!). Vamos nessa!

O que é o ciclo de vida de um serviço e por que ele é importante?

Imagine que sua aplicação é um restaurante. Os serviços são os cozinheiros, garçons e a louça. O ciclo de vida define por quanto tempo eles "vivem":

\n
• Transient (Transiente) — um funcionário descartável. Chega, faz um prato de sopa e vai embora. Novo pedido, novo funcionário.
\n
• Scoped (Escopo) — um funcionário para um turno inteiro. Atende todos os clientes enquanto o restaurante está aberto (enquanto dura a requisição HTTP).
\n
• Singleton (Único) — o chef principal, que trabalha durante toda a vida do restaurante. Apenas um para toda a aplicação.
\n

Em C#, essa lógica é implementada através do contêiner DI embutido. Vamos ver o código.

1. AddTransient — uma nova instância a cada vez

Quando usar: Serviços leves e sem estado (stateless), que não armazenam dados entre chamadas. Ideal para repositórios, helpers e utilitários.

Como funciona: Cada vez que você solicita o serviço (através do construtor ou diretamente do contêiner), um novo objeto é criado.

// Registro em Program.cs\nbuilder.Services.AddTransient<IMyService, MyService>();\n\n// Exemplo de serviço\npublic interface IMyService\n{\n    Guid GetInstanceId();\n}\n\npublic class MyService : IMyService\n{\n    private readonly Guid _id = Guid.NewGuid();\n    public Guid GetInstanceId() => _id;\n}\n\n// Controller que usa o serviço\npublic class HomeController : Controller\n{\n    private readonly IMyService _service1;\n    private readonly IMyService _service2;\n\n    public HomeController(IMyService service1, IMyService service2)\n    {\n        _service1 = service1;\n        _service2 = service2;\n    }\n\n    public IActionResult Index()\n    {\n        ViewBag.Id1 = _service1.GetInstanceId();\n        ViewBag.Id2 = _service2.GetInstanceId();\n        // Id1 e Id2 — GUIDs DIFERENTES!\n        return View();\n    }\n}\n

Importante: Mesmo dentro de uma única requisição HTTP, se você injetar IMyService em dois lugares diferentes, receberá dois objetos distintos. Mais consumo de memória, mas sem risco de "contaminação" de dados.

2. AddScoped — uma instância por requisição

Quando usar: Serviços que precisam ser consistentes dentro de uma mesma requisição HTTP. Por exemplo, DbContext no Entity Framework Core, serviços de carrinho de compras ou loggers de requisição.

Como funciona: Dentro de uma mesma requisição HTTP (ou escopo), uma única instância é criada. Se você solicitá-la várias vezes, receberá o mesmo objeto. Mas cada nova requisição de outro usuário terá sua própria instância.

// Registro\nbuilder.Services.AddScoped<IScopedService, ScopedService>();\n\npublic interface IScopedService\n{\n    Guid GetInstanceId();\n}\n\npublic class ScopedService : IScopedService\n{\n    private readonly Guid _id = Guid.NewGuid();\n    public Guid GetInstanceId() => _id;\n}\n\n// No mesmo controller\npublic