Así que las aplicaciones ASP.NET Core tienen la Inyección de dependencias incorporada. Y con Entity Framework Core, puede obtener fácilmente una instancia de DbContext con ámbito desde un método de acción del controlador.

Pero todo esto se limita a las acciones del controlador. Si necesita iniciar una tarea en segundo plano de larga duración a partir de una acción que se comunicará con la vista en el navegador por otros medios como WebSocket, entonces de repente no tiene nada en absoluto. La tarea en segundo plano no puede usar el DbContext de la acción porque se definió y eliminó cuando la acción regresa.

Una manera fácil sería usar lo que las personas llaman Localizador de servicios. Esta es una copia estática de algunos IServiceProvider para acceso posterior y resolución de servicios. (ASP.NET Core 2.1 podría necesitar un enfoque diferente, ya que he leídoen este comentario.) Pero dondequiera que mire, esto se describe como antipatrón. Hace que las pruebas sean más difíciles y ofusca las dependencias. Bien

Entonces, ¿cuál es la solución recomendada para este escenario? Estoy en algún lugar en el medio de la nada. Una tarea en segundo plano que incluso podría iniciarse desde un planificador en lugar de una acción del controlador. No hay solicitud HTTP en ningún lugar cercano. ¿Qué puede hacer DI por mí aquí? ¿Existe una solución sin recurrir a los antipatrones? Estoy seguro de que los creadores de ASP.NET Core DI han pensado en esto.

¿Hay alguna forma de resolver los servicios allí o cambiar mi arquitectura para que la tarea en segundo plano salga de DI de alguna manera?

Actualizar Solicitado por un comentario, un ejemplo: una acción de controlador inicia algo. Esto llevará mucho tiempo, como un escaneo de red. La vista vuelve con algo como "Estimado usuario, espere mientras puede ver esta barra de progreso". El trabajo continúa en segundo plano, publicando continuamente el progreso y / o resultados en el navegador. (El navegador también puede sondear el progreso). La tarea en segundo plano necesita acceso a la base de datos para almacenar los resultados del análisis. Cuando finaliza el escaneo, el navegador puede recuperarlo mediante otra acción. Entonces, si la tarea en segundo plano simplemente usara el DbContext de la acción del controlador, quedaría inutilizable cuando la acción se haya completado.

Otro ejemplo es un servicio en segundo plano que no está relacionado en absoluto con una solicitud. Un servicio que verifica regularmente la base de datos y luego hace algo. Eso también necesita un DbContext y no tiene dónde intentar robarlo.