Использование HttpContext.Current в WebApi опасно из-за асинхронности

Мой вопрос немного связан с этим:Эквивалент WebApi для HttpContext.Items с внедрением зависимостей.

Мы хотим внедрить класс, используя HttpContext.Current в области WebApi, используя Ninject.

Мое беспокойство, это может бытьочень опасно, как в WebApi (все?) является асинхронным

Пожалуйста, поправьте меня, если я ошибаюсь в этих пунктах, это то, что я исследовал до сих пор:

HttpContext.Current получает текущий контекст по Thread (я смотрел непосредственно на реализацию).

Использование HttpContext.Current внутри асинхронной задачи невозможно, поскольку она может выполняться в другом потоке.

WebApi использует IHttpController с методомTask<HttpResponseMessage> ExecuteAsync => каждый запрос асинхронный => вы не можете использовать HttpContext.Current внутри метода действия. Это может даже произойти, больше запросов выполняется в том же потоке по совпадению.

Для создания контроллеров с внедренным материалом в конструкторы используется IHttpControllerActivator ссинхронизировать методIHttpController Create, Здесь ninject создает Controller со всеми его зависимостями.

Если я прав во всех этих 4 пунктах, использование HttpContext.Current внутри метода действия или любого слоя ниже очень опасно и может привести к неожиданным результатам. Я видел на ОЧЕНЬ большом количестве принятых ответов, предлагающих именно это. ИМХО, это может работать некоторое время, но не под нагрузкой.

Но при использовании DI для создания контроллера и его зависимостей это нормально, потому что это выполняется в одном отдельном потоке.Я мог бы получить значение из HttpContext в конструкторе, и это будет безопасно?, Интересно, каждый ли контроллер создается в одном потоке для каждого запроса, так как это может вызвать проблемы при больших нагрузках, когда все потоки из IIS могут быть использованы.

Просто чтобы объяснить, почему я хочу внедрить материал HttpContext:

Одним из решений было бы получить запрос в методе действия контроллера и передать необходимое значение всем слоям в качестве параметров, пока оно не будет использовано где-то глубоко в коде.

Наше желаемое решение: все слои между ними не затрагиваются, и мы можем использовать внедренный запрос где-то глубоко в коде (например, в некотором ConfigurationProvider, который зависит от URL)

Пожалуйста, дайте мне свое мнение, если я полностью неправ или мои предложения верны, так как эта тема кажется очень сложной. Спасибо заранее!

Ответы на вопрос(3)

Ваш ответ на вопрос