Всегда использовать Async в контроллере ASP.NET MVC

Я недавно унаследовал проект ASP.NET MVC. В этом проекте разработчик использует async везде . Я пытаюсь оценить, если это хорошая идея или нет. В частности, я сейчас проверяю код контроллера.

В контроллерах разработчик написал что-то вроде следующего:

public async Task<ActionResult> Index()
{
  return View();
}

Есть ли в этом преимущество перед традиционной версией:

public ActionResult Index()
{
  return View();
}

Я могу понять, используя async if await был использован в коде контроллера. Много раз, хотя он не используется. Есть ли основания для такого подхода?

4 голоса | спросил user687554 13 SatEurope/Moscow2014-12-13T18:40:22+03:00Europe/Moscow12bEurope/MoscowSat, 13 Dec 2014 18:40:22 +0300 2014, 18:40:22

2 ответа


0

Нет. Это не очень хорошая идея использовать Async везде.

Относительно пропущенного ожидания, компилятор выдает предупреждение, когда метод Async не содержит Await оператор. Асинхронный метод без ожидания будет работать синхронно, что делает семантику некорректной.

Для вашего конкретного примера операция проста и непродолжительна, и поэтому использование Async /Await не приносит никаких преимуществ, и его не следует использовать, так что вы прекрасно работаете с:

public ActionResult Index()
{
    return View();
}

Async /Await следует использовать для методов контроллера, которые выполняют какой-либо ввод-вывод (например, сетевые запросы, доступ к базе данных и т. д.). Если метод контроллера выполняет работу с привязкой к процессору (например, математические вычисления), то использование Async /Await может на самом деле ухудшить производительность, если ваши измерения не докажут, что я не прав.

Применяется старое правило: Измерьте дважды, отрежьте один раз .

ответил Faris Zacina 13 SatEurope/Moscow2014-12-13T18:44:11+03:00Europe/Moscow12bEurope/MoscowSat, 13 Dec 2014 18:44:11 +0300 2014, 18:44:11
0

Нет смысла создавать действие /метод, если в этом методе нет await. Создание метода async означает, что "под коробкой" (компилятором) будет создан конечный автомат, который делает небольшую нагрузку по сравнению с чистой версией void ( действительно небольшие накладные расходы, но если у вас миллионные запросы в секунду, это может иметь значение;)). Если вы боитесь, что скоро может появиться ожидание (вам лучше иметь веские основания для «испугания»), и у вас много кода, зависящего от этого метода (например, это метод абстрактного класса /он принадлежит интерфейсу), вам следует сохранить метод, возвращающий Task<ActionResult>, но не помечая его как асинхронный. Пример:

public Task<ActionResult> MyAction() {

    return Task.FromResult<ActionResult>(View());
}

Этот метод Task.FromResult<T> возвращает выполненную задачу, что не позволяет компилятору создавать асинхронный конечный автомат.

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

ответил fex 13 SatEurope/Moscow2014-12-13T18:53:50+03:00Europe/Moscow12bEurope/MoscowSat, 13 Dec 2014 18:53:50 +0300 2014, 18:53:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132