Convenções de injeção de dependência no .NET: tempos de vida, escopos e a armadilha da dependência capturada

O que é

A documentação do .NET descreve um contêiner embutido: os serviços são adicionados a um IServiceCollection na inicialização (AddTransient, AddScoped, AddSingleton ou as variantes com chave), BuildServiceProvider ou o host genérico cria o IServiceProvider, e os consumidores recebem as dependências por um construtor público. Serviços transient são criados a cada vez que são solicitados; serviços scoped, uma vez por escopo, que no ASP.NET Core corresponde à requisição; singletons, uma única vez durante todo o tempo de vida do contêiner. O contêiner descarta o que criou: instâncias transient e scoped ao final do seu escopo, singletons no encerramento. Quando um tipo tem vários construtores, é escolhido o que tem mais parâmetros resolvíveis por DI; se houver ambiguidade, é lançada uma exceção.

Por que importa

Quem vem do Spring (singleton por padrão) ou de frameworks sem contêiner costuma registrar tudo como singleton ou resolver os serviços manualmente. A página de diretrizes dá ao bug resultante o nome de dependência capturada (captive dependency): um serviço de vida mais longa mantém uma referência a um de vida mais curta, de modo que um DbContext "por requisição" capturado por um singleton passa a ser compartilhado, sem aviso, por todas as requisições. A página sobre tempos de vida afirma que um serviço scoped não deve ser resolvido a partir de um singleton, nem por injeção no construtor nem por meio de IServiceProvider; a correção documentada é criar um escopo explícito com IServiceScopeFactory.

Como aplicar

• Use transient como padrão para serviços sem estado, scoped para estado por requisição (DbContext, unit of work) e singleton apenas para estado compartilhado, thread-safe e custoso; as diretrizes dizem que singletons precisam ser thread-safe e alertam para acoplamento e consumo de memória.
• Dependa de interfaces nos construtores e não faça neles nada além de atribuições.
• Nunca chame Dispose em um serviço injetado e não registre tipos IDisposable como transient quando puderem ser resolvidos a partir do provider raiz; segundo as diretrizes, essas instâncias ficam retidas até o contêiner ser descartado.
• Não chame BuildServiceProvider durante a configuração dos serviços e não use GetService como service locator; ambos constam como antipadrões.
• Mantenha a validação de escopo ligada: o host em ambiente de desenvolvimento verifica que serviços scoped não são resolvidos a partir da raiz nem injetados em singletons, e validateScopes: true em BuildServiceProvider faz o mesmo nos demais casos.
• Em serviços hospedados ou em segundo plano, injete IServiceScopeFactory e crie um escopo para cada unidade de trabalho.

Armadilhas

O acesso estático ao provider (um ApplicationServices capturado) consta como algo a evitar: segundo as diretrizes, os benefícios da DI se perdem quando ela é misturada com acesso estático a objetos. Outra armadilha é guardar configuração ou dados de usuário no contêiner em vez de usar o padrão de opções (options pattern). Serviços com chave exigem [FromKeyedServices("key")] no parâmetro. Registrar um serviço duas vezes é permitido e fácil de passar despercebido.