Tag: dependency-injection

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.

O ASP.NET Core lança esta exceção quando um construtor pede um tipo que nunca foi registrado, foi registrado no contêiner errado ou foi adicionado depois que o host foi construído. Três correções concretas cobrem quase todos os casos.

EF Core 11 Preview 3 introduz RemoveDbContext, RemoveExtension, e um overload sem parâmetros do AddPooledDbContextFactory, removendo o boilerplate de trocar providers em testes e centralizando a configuração da pooled factory.