Tag: dependency-injection

Antes do Aspire 13.5.4, cada health check do AppHost em um recurso AddKafka criava um novo producer do Confluent que ninguém descartava, então as threads de polling se acumulavam e o AppHost queimava CPU. A correção, e a armadilha do HealthCheckRegistration.Factory por trás dela, vale também para os seus próprios health checks.

Um singleton não pode injetar um DbContext, mas pode injetar IDbContextFactory<T>, porque AddDbContextFactory registra a fábrica como singleton por padrão. Crie e descarte um contexto por chamada, nunca guarde a instância.

Implemente IValidateOptions<T>, registre na DI e encadeie ValidateOnStart para que um appsettings.json ruim derrube o processo em vez da primeira requisição que tocar nele. Cobre a sobrecarga Validate<TValidator>() do .NET 11, validação assíncrona com IAsyncValidateOptions<T> e os três lugares onde ValidateOnStart silenciosamente não faz nada.

Use IOptions<T> por padrão. Use IOptionsMonitor<T> quando um singleton precisa enxergar recargas de configuração, e IOptionsSnapshot<T> apenas quando um consumidor scoped precisa de um valor estável durante uma requisição. O eixo que decide é o tempo de vida do consumidor, não o formato das configurações.

O EF Core lança isso quando AddDbContext nunca rodou, rodou depois de Build ou o construtor do contexto recebe o DbContextOptions errado. Registre antes de Build e use DbContextOptions<SeuContexto>.

Registre várias implementações do mesmo tipo de serviço sob uma chave com AddKeyedSingleton/Scoped/Transient e depois resolva-as com [FromKeyedServices], GetRequiredKeyedService ou KeyedService.AnyKey. Os registros com chave e sem chave são tabelas separadas, e esse é o detalhe que pega quase todo mundo.

Um BackgroundService é um singleton, então não pode injetar diretamente um serviço scoped como um DbContext. Receba IServiceScopeFactory, abra um scope por unidade de trabalho com CreateAsyncScope, resolva dentro dele e descarte-o quando o trabalho terminar.

Uma lista de verificação passo a passo para remover o MediatR 12-14 e substituir os handlers de IRequest, ISender, os pipeline behaviors e INotification por classes de serviço simples e injeção por construtor.

Para código novo, classes de serviço simples são a melhor opção padrão. A mudança de licença do MediatR de julho de 2025 só importa se você estiver acima do limite Community de 5 milhões de dólares ou recusar o copyleft da RPL-1.5. Mantenha o MediatR quando os pipeline behaviors forem essenciais.

A validação de escopo do ASP.NET Core lança esta exceção quando um singleton capturaria uma dependência scoped pelo resto do processo. Torne o consumidor scoped, ou injete IServiceScopeFactory e crie um escopo sob demanda.