Разъяснение событий против наблюдателя против процессора почтовых ящиков в F # - PullRequest
Новая
       13

Разъяснение событий против наблюдателя против процессора почтовых ящиков в F #

3 голосов
/ 26 мая 2020

У меня есть система, подключенная к финансовым рынкам, которая очень интенсивно использует события.

Весь код структурирован как каскад событий с фильтрами, агрегатами и c между ними.

Первоначально система была написана на C#, а затем перенесена на F # (что, в ретроспективе, было отличным ходом), а события в коде C# были заменены событиями на F #, не вдаваясь в подробности.

Я слышал о шаблоне наблюдателя, но на самом деле не изучал топи c. И недавно я прочитал, путем случайного просмотра, о процессоре почтовых ящиков F #.

Я прочитал это: Разница между шаблоном наблюдателя и подходом, управляемым событиями , и я не понял, но, видимо, более 150 человек проголосовали за то, что ответ тоже был не слишком ясным :)

В такой статье: https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c кажется, что шаблон наблюдателя строго идентичен событиям ...

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

  • Действительно ли используется процессор почтовых ящиков? кажется, что он появляется в основном в более старой документации, и в используемых мной пакетах я не встречал, чтобы кто-либо его использовал

  • Что касается шаблона наблюдателя, только один пакет в большом количество, которое мы используем, использует его для внутреннего использования, но все остальное использует только базовые c события.

Существуют ли конкретные c варианты использования, соответствующие шаблону Observable и MailboxProcessor ? Есть ли у них уникальные особенности? или они просто синтаксис c помогают обойти события в конце?

1 Ответ

2 голосов
/ 26 мая 2020

Максимально упрощено:

Почтовый ящик

Это минимальная реализация модели актора . Вы отправляете сообщения в очередь, и ваш l oop читает сообщения из очереди одно за другим. Может быть, он отправляет сообщения в другой почтовый ящик или что-то делает с сообщениями.

  • Любое действие может быть только , когда сообщение получено.
  • Размещение в очереди неблокирующее, т. Е. Без обратного давления.
  • Все исключения перехватываются и отображаются как событие в почтовом ящике. Ожидается, что они будут обрабатываться вышестоящим субъектом.
  • Другие структуры акторов предоставляют такие функции, как супервизоры, контракты, отработка отказа и т. Д. c.

События

События - это механизм обратного вызова, поддерживаемый языком.

Это простая реализация. Вы регистрируете делегата обратного вызова, и при возникновении события вызывается ваш делегат.

  • Делегаты вызываются в том порядке, в котором они добавляются.
  • События блокируются и синхронны. Один делегат блокирует, остальные задерживаются.
  • События связаны с написанием кода для ответа на события, в отличие от того, что было до него, а именно опроса.
  • Обработчик события обычно является конечной конечной точкой для этого события и обычно имеет побочные эффекты.
  • Совместное использование обработчика - обычное дело. Например, десять кнопок могут иметь одну и ту же функцию обработки щелчков, поскольку отправитель события известен.
  • Вы обрабатываете исключения самостоятельно, обычно в коде обработчика

Observables

Есть источник (Observable), на который вы можете подписаться с помощью приемника (Observer). Наблюдаемый представляет собой ограниченный или неограниченный поток значений. Неограниченный поток (Observable, который никогда не завершается) кажется похожим на событие, но у Observables есть несколько важных свойств.

  • Observable отправляет серию уведомлений, следующих за этим контрактом: 
    OnNext* (OnError|OnCompleted)+
  • Все уведомления сериализуются
  • Уведомления могут быть или не быть синхронными. Нет никакой гарантии противодавления.
  • Ценность Observables заключается в том, что они могут быть составлены.
  • Observable представляет поток будущих уведомлений, операторы действуют, чтобы преобразовать этот поток.
  • Этот подход иногда называют комплексной обработкой событий (CEP).
  • Обработка исключений является частью конвейера, и есть много комбинаторов, которые справляются с этим.
  • Обычно вы никогда не реализуете Observer самостоятельно. Вы используете комбинаторы для настройки конвейера, который моделирует желаемое поведение.
...