Выбор не ждать асинхронной функции в действии в контроллере ASP.NET Core WebAPI - PullRequest
Новая
       13

Выбор не ждать асинхронной функции в действии в контроллере ASP.NET Core WebAPI

0 голосов
/ 01 февраля 2019

Сценарий выглядит следующим образом:

  • Серверная часть: Asp.NET Core WebAPI 2.2
  • Внешний интерфейс: iOS и Android, использующий API

У меня есть функция, позволяющая пользователю отправлять сообщения другим пользователям.Отправка сообщения выполняется в асинхронном действии:

public async Task<IActionResult> CreateMessage

Это действие выполняет следующие действия по порядку:

  1. Проверка
  2. Ожидает сохранения сообщения в БД
  3. Ожидает уведомления соответствующих клиентов через SignalR
  4. Не ожидает отправки push-уведомления через Azure Notification Hub.
  5. Возвращает 200 OK.

Последние две строки в действии следующие: 

_notificationHubProxy.SendNotification(messageToReturnResource.SenderName, messageToPush, recipientId);

return Ok(messageToReturnResource);

SendNotification является асинхронным, но я предпочитаю не ждать его, чтобы избежатьUI-блокировки вызваны ожиданием завершения запроса.На данный момент все это, кажется, работает нормально.

Мой вопрос на самом деле следующий: это окей (т.е. не ждать), или это пример написания плохого кода, который вызовет проблемы, когда у меня многоклиенты, использующие приложение?

С уважением

1 Ответ

0 голосов
/ 01 февраля 2019

Есть несколько проблем с fire-and-Forgot в ASP.NET (как Core, так и Classic) :

  • Любые исключения будут игнорироваться.
  • Приложение не может определить, когда операция завершена.Это означает, что все, что «выше» этого кода, не знает, что ваш код все еще что-то делает;ASP.NET, IIS и ваш балансировщик нагрузки не имеют представления о том, что ваше приложение все еще выполняет что-то .Некоторые из них - системы управления, которые могут (и будут) закрывать ваше приложение.Например, IIS выполняет регулярную утилизацию AppPool.

Варианты использования Fire и Forget в ASP.NET гораздо реже, чем думает большинство людей.Вы не только должны быть в порядке с тихим глотанием ошибок, но вы также должны быть в порядке с случайной потерей этой работы.

Я предпочитаю не ждать этого, чтобы избежать блокировок пользовательского интерфейса, вызванных ожиданиемзапроса на завершение.

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

...