Написал программу импорта данных в БД из внешнего REST-сервиса.
Программа написана как консольное приложение на dot net core на языке C#.
Она запускается по расписанию каждые 30 минут из Sheduler'а Windows.
Основный цикл имеет вид:
Данные = СчитатьДанныеИзREST();
while (Данные != NULL) {
СохранитьДанныеВБд(Данные);
Данные = СчитатьДанныеИзREST();
}
Сейчас я написал программу без использования асинхронных методов получения данных и их записи в БД. Для получения данных из REST и сохранения их в БД использую синхронные методы:
- WebRequest GetResponse() - для получения данных из REST
- Dapper Execute() - для сохранения данных в БД
Как видно из псевдокода основного цикла программы, данные запрашиваются и обрабатываются сугубо последовательно. И это меня полностью устраивает - мне нет необходимости обрабатывать их параллельно/асинхронно. Программа никак не работает с потоками (Threads) и одновременно не будут запускаться несколько копий программы.
Однако для получения данных из REST и сохранения их в БД можно использовать асинхронные версии тех же методов (ИмяМетодаAsync):
- WebRequest GetResponseAsync() - для получения данных
- Dapper ExecuteAsync() - для сохранения данных в БД
Вопрос: имеется ли причина переделывать программу, чтобы она использовала асинхронные методы вместо синхронных? Есть ли от этого какие-нибудь плюсы в тех условиях, что я описал? Плюсы вроде: исполняющая среда dot net core будет экономнее использовать процессоров время/ресурсы для других задач, а сейчас она просто тупо висит в ожидании, когда идет ожидание получения данных из REST или при сохранении данных в БД?
Я понимаю, как писать async/await при вызове и в декларациях функций. Для меня это не проблема. Я понимаю, что вместо обычного метода будет сгенерирован системой автомат состояний, что будет кушать ресурсы.
Вопрос можно переформулировать более обще:
имеет ли смысл использовать асинхронные вызовы в консольных программах Don net core, если алгоритм обработки последователен? 
