F# 中的事件、觀察者和郵箱處理器的澄清

Question

我有一個與金融市場相連的系統，它大量使用事件。

所有代碼都被構造為級聯事件，中間有過濾器、聚合等。

Originally the system was written in C# and then ported to F# (which in retrospect was a great move) and events in the C# code got replaced by events in F# without giving it much thoughts.

我聽說過觀察者模式，但我還沒有真正了解過這個話題。 最近，我通過一些隨機瀏覽閱讀了有關 F# 的郵箱處理器的信息。

我讀到這個： 觀察者模式和事件驅動方法之間的區別，我沒有明白，但顯然超過 150 人投票認為答案也不太清楚:)

在這樣的文章中：https://hackernoon.com/observer-vs-pub-sub-pattern-50d3b27f838c似乎觀察者模式與事件完全相同......

乍一看，他們似乎在解決同一種問題，只是界面不同，但這讓我想到了兩個問題：

• 郵箱處理器真的是被使用的東西嗎？ 它似乎主要出現在較舊的文檔中，並且在我正在使用的軟件包中，我沒有遇到任何使用它

• 關於觀察者模式，在我們使用的相當大的數量中，只有一個 package 在內部使用它，但其他一切都只是使用基本事件。

是否有適合 Observable 模式和 MailboxProcessor 的特定用例？ 它們是否具有獨特的功能？ 還是它們最終只是圍繞事件的句法幫助？

Answer 1

盡可能簡化：

郵箱

這是演員 model的最小實現。 您將消息發布到隊列，然后您的循環從隊列中一一讀取消息。 也許它會發布到另一個郵箱，或者它對消息做一些事情。

• 任何動作都只能在收到消息時發生。
• 發布到隊列是非阻塞的，即沒有背壓。
• 所有異常都被捕獲並作為郵箱上的事件公開。 他們預計將由它上面的演員處理。
• 其他參與者框架提供了監管者、合同、故障轉移等功能。

活動

事件是一種語言支持的回調機制。

這是一個簡單的實現。 您注冊一個回調委托，當事件引發時，您的委托被調用。

• 代表按它們添加的順序被調用。
• 事件是阻塞的，並且是同步的。 一個代表塊 rest 被延遲。
• 事件是關於編寫代碼來響應事件，而不是之前發生的事情，即輪詢。
• 事件的處理程序通常是該事件的最終端點，並且通常具有副作用。
• 共享處理程序很常見。 例如，十個按鈕可能具有相同的 function 處理點擊，因為事件的發送者是已知的。
• 您自己處理異常，通常在處理程序代碼中

可觀察的

有一個源（Observable），您可以使用接收器（Observer）訂閱它。 一個 observable 代表一個有界或無界的 stream 值。 一個無界的 stream（一個永遠不會完成的 Observable）看起來類似於一個事件，但是 Observable 有幾個重要的屬性。

• 一個 Observable 發出一系列通知，這些通知遵循這個協定：

    OnNext* (OnError|OnCompleted)+

• 所有通知都是序列化的
• 通知可能是同步的，也可能不是同步的。 不能保證背壓。
• Observables 的價值在於它們是可組合的。
• 一個 observable 代表一個未來通知的 stream，操作員采取行動來轉換這個 stream。
• 這種方法有時稱為復雜事件處理 (CEP)。
• 異常處理是管道的一部分，有很多組合器來處理它。
• 您通常從不自己實現觀察者。 您使用組合器來設置一個管道，該管道對您想要的行為進行建模。