образом, в приложениях ASP.NET Core встроен Dependency Injection. А с Entity Framework Core вы можете легко получить экземпляр DbContext с областью видимости из метода действия контроллера.

Но это все ограничено действиями контроллера. Если вам нужно запустить длительную фоновую задачу из действия, которое будет взаимодействовать с представлением в браузере другими средствами, такими как WebSocket, то у вас вдруг ничего не останется. Фоновая задача не может использовать DbContext действия, потому что она была определена и удалена, когда действие возвращается.

Самый простой способ - использовать то, что люди называют сервисным локатором. Это статическая копия некоторого IServiceProvider для последующего доступа и разрешения службы. (ASP.NET Core 2.1 может потребоваться другой подход, как я прочиталв этом комментарии.) Но куда бы я ни посмотрел, это называется анти-паттерном. Это усложняет тестирование и запутывает зависимости. Хорошо.

Так что же является рекомендуемым решением для этого сценария? Я где-то в глуши. Фоновая задача, которая может даже запускаться из планировщика вместо действия контроллера. Нет HTTP-запроса где-либо рядом. Что я могу сделать для меня здесь? Есть ли решение, не обращаясь к анти-шаблонам? Я уверен, что создатели ASP.NET Core D я думал об этом.

Есть ли способ разрешить службы там или изменить мою архитектуру, чтобы фоновая задача как-то вышла из DI?

Обновить: Запрошенный комментарием, пример: действие контроллера запускает что-то. Это займет много времени, как сканирование сети. Представление возвращается с чем-то вроде «Уважаемый пользователь, пожалуйста, подождите, пока вы сможете наблюдать этот индикатор выполнения». Работа продолжается в фоновом режиме, постоянно публикуя результаты и / или результаты в браузере. (Браузер также может опрашивать ход выполнения.) Для фоновой задачи необходим доступ к базе данных для сохранения результатов сканирования. Когда сканирование завершено, браузер может получить его с помощью другого действия. Так что, если фоновая задача будет просто использовать DbContext действия контроллера, это станет непригодным для использования после завершения действия.

Другим примером является фоновая служба, которая вообще не связана с запросом. Служба, которая регулярно проверяет базу данных, а затем что-то делает. Это также нуждается в DbContext и некуда даже пытаться его украсть.