Длительный асинхронный метод против запуска события по завершении - PullRequest
Новая
       32

Длительный асинхронный метод против запуска события по завершении

0 голосов
/ 25 апреля 2019

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

В одной из функций мне нужно выполнить команду, затем подождать несколько секунд, пока она выполняет тест (варьируется от 10 до 1000 секунд), и вернуть результат теста:

Один из подходов - использовать шаблон async-await: 

public async Task<decimal> TaskMeasurementAsync(CancellationToken ctx = default)
{
    PerformTheTest();

    // Wait till the test is finished
    await Task.Delay(_duration, ctx);

    return ReadTheResult();
 }

Другое, что приходит на ум, это просто запустить событие по завершении.

Устройство выполняет тестирование, и продолжительность указывается перед его выполнением. Так что в любом случае мне пришлось бы использовать Task.Delay() или Thread.Sleep(), чтобы дождаться завершения задачи на устройстве.

Я склоняюсь к async-await, так как его легко встроить в отмену и из-за отсутствия лучшего термина, он самодостаточен, т.е. мне не нужно объявлять событие, создавать класс EventArgs и т. Д.

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

Спасибо.

1 Ответ

1 голос
/ 25 апреля 2019

Существует несколько инструментов, позволяющих структурировать ваш код.

События являются моделью push (как и System.Reactive, также известная как LINQ over events).«).Идея состоит в том, что вы подписываетесь на событие, а затем ваш обработчик вызывается ноль или более раз.

Задачи - это модель pull .Идея состоит в том, что вы начинаете какую-то операцию, и Task сообщит вам, когда она завершится.Недостатком задач является то, что они представляют только один результат.

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

В вашем случае вы запускаете операцию (тест), ожидаете ее завершения и затем читаете результат.Это звучит очень похоже на модель pull , которая подходит здесь, поэтому я рекомендую Task<T> over events / Rx.

...