IHttpActionResult vs async Задача <IHttpActionResult>

Большинство методов Web API 2.0 я видел return IHttpActionResult, который определяется как интерфейс, который "определяет команду, которая асинхронно создает System.Net.Http.HttpResponseMessage".

Я немного смущен тем, что происходит, когда метод возвращает async Task<IHttpActionResult>.

Почему вы используете один над другим? Или они функционально идентичны - не IHttpActionResult уже асинхронны?

Ответы

Ответ 1

Разница между использованием IHttpActionResult и async Task<IHttpActionResult> заключается в том, использует ли какой-либо из вашего кода функции async и await. Многие библиотеки, такие как Entity Framework, предоставляют версии методов async (например, SaveChangesAsync), которые обеспечивают небольшое увеличение производительности. Однако есть проблемы с использованием async с веб-API, поэтому, если вы не понимаете многие особенности, разумно придерживаться синхронного API.

У Стивена Клири есть много информации о его блоге об особенностях async и await. Для начала я советую посмотреть Не блокировать асинхронный код.

Ответ 2

Ваше действие может вернуть IHttpActionResult, который выполняет асинхронное действие, когда инфраструктура вызывает его ExecuteAsync.

Но если вы должны сначала сделать другие асинхронные вызовы перед созданием и возвратом результата, вам придется изменить подпись на async Task<IHttpActionResult>. Это все, что есть.

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

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

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

Соблюдайте осторожность перед вызовом Wait или Result в задаче или созданием задачи самостоятельно в коде ASP.NET.

Две законные причины для ручного кода, преднамеренной многопоточности или parallelism для кода веб-сервера:

  • когда он получает минимальный трафик, но выполняет вычислительную работу, вызов так часто, чтобы выполнить вычисление по данным, и вы хотите использовать все 16 ядер.
  • при выполнении > 1 одновременных звонков в осколки базы данных или > 1 других сервисов, вы должны выполнить задачу для каждого запроса осколка впереди и ждать их всех.