Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
À luz das boas práticas de DI e lifetimes no ASP.NET Core, qual conjunto de correções a...
À luz das boas práticas de DI e lifetimes no ASP.NET Core, qual conjunto de correções alinha o projeto com dependências explícitas, testáveis e seguras para concorrência?
A
Manter ProcessingService e EmailSender como Singleton, trocando IOptionsSnapshot por IOptionsSnapshot (inalterado) e guardando um IServiceProvider interno para criar AppDbContext sob demanda; seguir com HttpClient direto e property injection em EmailSender.
B
Tornar tudo Transient para evitar estado compartilhado; injetar HttpClient estático por desempenho; manter Service Locator no controlador porque “flexibiliza” a resolução.
C
Usar injeção por construtor em todas as classes; registrar ProcessingService como Scoped; substituir HttpClient por IHttpClientFactory; usar IOptionsMonitor em singletons e IOptionsSnapshot apenas no escopo da requisição; no SyncWorker, criar um escopo por iteração com IServiceScopeFactory e resolver serviços Scoped dentro dele; em cenários de background que precisam de EF, preferir IDbContextFactory<AppDbContext>; remover property injection obrigatória e o Service Locator do controlador.
D
Promover AppDbContext a Singleton para casar com ProcessingService singleton; substituir IOptionsSnapshot por valores lidos de IConfiguration diretamente; manter HttpClient direto e injetar o ProcessingService no SyncWorker sem criação de escopos.
E
Trocar ProcessingService para Scoped, mas manter IOptionsSnapshot dentro de EmailSender Singleton; continuar com Service Locator apenas nos controladores e usar HttpClient direto, pois o AddHttpClient já foi chamado.