Использование 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)
Пожалуйста, дайте мне свое мнение, если я полностью неправ или мои предложения верны, так как эта тема кажется очень сложной. Спасибо заранее!