0

Помогите грамотно подойти к решению задачи.

Есть много асинхронных ззадач, которые по snmp периодически опрашивают параметры девайсов.

Результаты должны:

  1. сохраниться в бд.
  2. отображаться на экране.
  3. отправляться в почту или еще куда.

Думал сделать так:

  1. используя channel из System.Threading записывать в него результаты задач.
  2. читать из channel и бросать события с прочитанными данными.
  3. бд, экран, почта подпишутся на эти события и будут делать свою работу с полученными в событии данными.

Ощущение, что либо события здесь лишние, либо каналы.

Кажется, что достаточно чтобы таски просто сразу кидали события.

Как такую задачу лучше решить?

Upd. Не плохая иллюстрация, того как можно сделать. Теперь более менее понятно для себя. Единственное, плохо или нет, если все задачи будут сразу бросать события?введите сюда описание изображения

Upd. подумал, что таки очередь нужна или синхронизация, иначе в бд окажется не актуальное состояние.

dmitriy
  • 452
  • что такое channel и куда вы хотите бросать события? – tym32167 Dec 09 '22 at 17:32
  • вообще не понял назначение тасков если честно. Если вам надо с периодичностью опрашивать устройства, вам нужен таймер. Что такое таски? – tym32167 Dec 09 '22 at 17:32
  • @tym32167 Task и Channel из System.Threading – dmitriy Dec 09 '22 at 17:36
  • @tym32167 неважно таймеры или таски. Таймеры тоже в пулле потоков отрабатывают. Тоже самое я могу сделать с while(true) await Task.Delay... – dmitriy Dec 09 '22 at 17:38
  • Немного отредактировал описание – dmitriy Dec 09 '22 at 17:44
  • у вас просто стоит тег "архитектура", потому я подумал что таски - это какой то элемент вашей доменной области, а не конкретный класс из дотнетов. Если вопрос просто о том, надо вам Channel или не надо, то это "зависит" от того, как вы всё это собираетесь синхронизировать. Например, если у вас 10 потоков выполняют таски, то channel вам может помочь обработку результата свести в один поток, так как если из 10 потоков кидать события, то обработчики событий могут отработать события не в хронологическом порядке и вы на UI можете пропустить свежую инфу и увидеть не свежую – tym32167 Dec 09 '22 at 17:45
  • хотя вообще это еще и от шины событий зависит, если она может сводить потоки в один или поддреживает очередность или это просто синхронная шина, которую даже вне UI потока нельзя юзать – tym32167 Dec 09 '22 at 17:46
  • с другой стороны, если вас не парит ни порядок событий, ни факт их параллельной обработки, то канал тогда не нужен конечно. Хотя я подозреваю, это должно вас парить ) – tym32167 Dec 09 '22 at 17:51
  • Кстати, если те же потоки, что обрабатывают девайсы, будут файрить события, и если события синхронные, то вы не только получите косяк на UI (так как там только события из UI потока должны обрабатываться), но еще и регулярность опросов нарушите или совсем можно поток уронить если обработчик упадет по какой то причине – tym32167 Dec 09 '22 at 17:53
  • @tym32167 Думал будет что-нибудь типа MonitoringService или DeviceWatcher. В нем стартуют 100500 задач, каждая со своей периодичностью. Что-то возвращают, результат заворачивается в нужную обертку и складывается в очередь.

    Одновременно с задачами опроса устройств стартует задача, которая очередь разбирает и выплевывает события. Кому надо подпишутся. Очередность вроде не важна. Подумаю на этот счет.

     – dmitriy Dec 09 '22 at 17:56
  • 1
    по сути задачи и очереди - это детали внутренней реализации MonitoringService/DeviceWatcher, я бы сделал интерфейс типа IDeviceWatcher и думал, как данные с него поедут куда либо. Очевидно, через события, но вот будет ли это событие частью IDeviceWatcher или у вас уже есть какая то общая шина событий в приложении - это уже вам решать. – tym32167 Dec 09 '22 at 18:01
  • а как задачи и очереди обрабатываются и будет ли там channel или нет - это просто деталь реализации IDeviceWatcher, которую можно поменять в любой момент – tym32167 Dec 09 '22 at 18:02
  • https://ru.stackoverflow.com/q/1303748/373567 – aepot Dec 09 '22 at 20:19
  • Вы уж определитесь, подписчики у вас (publisher/subscriber) или потребители (producer/consumer). А то пишете название одного, а рассказываете про другое. – aepot Dec 09 '22 at 20:21
  • 1
    @aepot подписчики. Поскольку они все должны получать одинаковое. Потребители, я так понимиаю не могут получать одинаковое, часть данных уходит одному, часть другому. А мне надо чтоб все получали все. – dmitriy Dec 10 '22 at 04:04
  • Тогда можно использовать обычный event, а если асинхронно, то как-то так https://ru.stackoverflow.com/a/1300322/373567. Channels вам не подходят. – aepot Dec 10 '22 at 09:08
  • @aepot channels я планировал использовать "внутри" в качестве очереди. Чтобы задачи опрашивали устройства и писали в канал. А другая задача разбирала из канала данные и посылала event. Лишнее? – dmitriy Dec 10 '22 at 09:29
  • Channel может обеспечить буферизацию очереди в этом случае, но по сути будет все работать в режиме 1-1 – aepot Dec 10 '22 at 09:31

0 Answers0