Portanto, os aplicativos ASP.NET Core possuem injeção de dependência incorporada. E com o Entity Framework Core, você pode facilmente obter uma instância DbContext com escopo definido a partir de um método de ação do controlador.

Mas tudo isso é limitado às ações do controlador. Se você precisar iniciar uma tarefa em segundo plano de longa execução a partir de uma ação que se comunique com a visualização no navegador por outros meios, como o WebSocket, de repente você não terá absolutamente nada. A tarefa em segundo plano não pode usar o DbContext da ação porque esse foi escopo e descartado quando a ação retorna.

Uma maneira fácil seria usar o que as pessoas chamam de localizador de serviço. Esta é uma cópia estática de alguns IServiceProvider para acesso e resolução de serviços posteriores. (O ASP.NET Core 2.1 pode precisar de uma abordagem diferente, como eu lineste comentário.) Mas onde quer que eu olhe, isso é descrito como antipadrão. Isso torna o teste mais difícil e ofusca as dependências. Tudo bem.

Então, qual é a solução recomendada para esse cenário? Estou em algum lugar no meio do nada. Uma tarefa em segundo plano que pode até ser iniciada a partir de um planejador em vez de uma ação do controlador. Nenhuma solicitação HTTP em qualquer lugar próximo. O que posso fazer por mim aqui? Existe uma solução sem voltar aos antipadrões? Tenho certeza que os criadores do ASP.NET Core DI pensaram nisso.

Existe uma maneira de resolver os serviços lá ou alterar minha arquitetura para que a própria tarefa em segundo plano saia do DI de alguma forma?

Atualizar: Solicitado por um comentário, um exemplo: Uma ação do controlador inicia algo. Isso levará muito tempo, como uma verificação de rede. A exibição retorna com algo como "Caro usuário, aguarde enquanto você pode assistir a esta barra de progresso". O trabalho continua em segundo plano, postando continuamente o progresso e / ou resultados no navegador. (O navegador também pode pesquisar o progresso.) A tarefa em segundo plano precisa acessar o banco de dados para armazenar os resultados da verificação. Quando a verificação é concluída, o navegador pode buscá-la através de outra ação. Portanto, se a tarefa em segundo plano usasse o DbContext da ação do controlador, isso se tornaria inutilizável à medida que a ação fosse concluída.

Outro exemplo é um serviço em segundo plano que não está relacionado a uma solicitação. Um serviço que verifica regularmente o banco de dados e, em seguida, faz alguma coisa. Isso também precisa de um DbContext e não tem nenhum lugar para tentar roubá-lo.