Mi pregunta está un poco relacionada con esto:WebApi equivalente para HttpContext.Items con inyección de dependencia.

Queremos inyectar una clase usando HttpContext.Current en el área de WebApi usando Ninject.

Mi preocupación es que esto podría sermuy peligroso, como en WebApi (¿todo?) es asíncrono.

Corríjame si me equivoco en estos puntos, esto es lo que investigué hasta ahora:

HttpContext.Current obtiene el contexto actual por Thread (investigué la implementación directamente).

Usar HttpContext.Current dentro de la tarea asíncrona no es posible, porque puede ejecutarse en otro subproceso.

WebApi utiliza IHttpController con métodoTask<HttpResponseMessage> ExecuteAsync => cada solicitud es asíncrona => no puede usar HttpContext.Current dentro del método de acción. Incluso podría suceder, más solicitudes se ejecutan en el mismo hilo por coincidencia.

Para crear controladores con material inyectado en constructores, IHttpControllerActivator se usa consincronizar métodoIHttpController Create. Esto es, donde ninject crea el controlador con todas sus dependencias.

Si estoy en lo correcto en todos estos 4 puntos, el uso de HttpContext.Current dentro de un método de acción o cualquier capa a continuación es muy peligroso y puede tener resultados inesperados. Vi en TANTO de respuestas aceptadas que sugieren exactamente esto. En mi humilde opinión, esto puede funcionar por un tiempo, pero fallará bajo carga.

Pero cuando se usa DI para crear un controlador y sus dependencias, está bien, porque esto se ejecuta en un hilo separado.¿Podría obtener un valor del HttpContext en el constructor y sería seguro?. Me pregunto si cada controlador se crea en un solo subproceso para cada solicitud, ya que esto podría causar problemas bajo cargas pesadas, donde todos los subprocesos de IIS podrían consumirse.

Solo para explicar por qué quiero inyectar cosas de HttpContext:

Una solución sería obtener la solicitud en el método de acción del controlador y pasar el valor necesario a todas las capas como parámetro hasta que se use en algún lugar profundo del código.

nuestra solución deseada: todas las capas intermedias no se ven afectadas por esto, y podemos usar la solicitud inyectada en algún lugar profundo del código (por ejemplo, en algún ConfigurationProvider que depende de la URL)

Dame tu opinión si estoy totalmente equivocado o si mis sugerencias son correctas, ya que este tema parece ser muy complicado. Gracias de antemano!