.NET: convenções de injeção de dependências — lifetimes, scopes e a armadilha da dependência cativa

O que é

A documentação do .NET descreve um container incorporado: os serviços são adicionados a um IServiceCollection no arranque (AddTransient, AddScoped, AddSingleton, ou variantes keyed), o BuildServiceProvider ou o host genérico cria o IServiceProvider, e os consumidores recebem as dependências através de um construtor público. Os serviços transient são criados de cada vez que são pedidos; os scoped, uma vez por scope, que no ASP.NET Core corresponde ao pedido; os singleton, uma vez para toda a vida do container. O container liberta (dispose) o que criou: as instâncias transient e scoped no final do respetivo scope, as singleton no encerramento. Quando um tipo tem vários construtores, é escolhido o que tiver mais parâmetros resolúveis por DI, e a ambiguidade gera uma exceção.

Por que importa

Engenheiros vindos do Spring (singleton por omissão) ou de frameworks sem container tendem a registar tudo como singleton ou a resolver serviços manualmente. A página de diretrizes dá ao bug resultante o nome de dependência cativa (captive dependency): um serviço de vida mais longa retém um de vida mais curta, pelo que um DbContext "por pedido" capturado por um singleton acaba silenciosamente partilhado por todos os pedidos. A página sobre lifetimes afirma que um serviço scoped não deve ser resolvido a partir de um singleton, seja por injeção no construtor seja através de IServiceProvider; a correção documentada é criar um scope explícito com IServiceScopeFactory.

Como aplicar

• Use transient por omissão para serviços sem estado, scoped para estado por pedido (DbContext, unit of work), e singleton apenas para estado partilhado, thread-safe e dispendioso; as diretrizes dizem que os singletons têm de ser thread-safe e alertam para problemas de acoplamento e memória.
• Dependa de interfaces nos construtores e mantenha os construtores livres de trabalho para além da atribuição.
• Nunca chame Dispose num serviço injetado, e não registe tipos IDisposable como transient quando possam ser resolvidos a partir do provider raiz; as diretrizes dizem que essas instâncias ficam retidas até o container ser libertado.
• Não chame BuildServiceProvider durante a configuração dos serviços, e não use GetService como service locator; ambos são listados como anti-padrões.
• Mantenha a validação de scopes ativa: o host de desenvolvimento verifica que os serviços scoped não são resolvidos a partir da raiz nem injetados em singletons, e validateScopes: true no BuildServiceProvider faz o mesmo noutros contextos.
• Em serviços hosted ou em segundo plano, injete IServiceScopeFactory e crie um scope por cada unidade de trabalho.

Armadilhas

O acesso estático ao provider (um ApplicationServices capturado) é listado como algo a evitar: as diretrizes dizem que os benefícios da DI se perdem quando ela é misturada com acesso estático a objetos. Guardar configuração ou dados de utilizador no container em vez de usar o options pattern. Os serviços keyed precisam de [FromKeyedServices("key")] no parâmetro. Registar um serviço duas vezes é válido e fácil de passar despercebido.