私は少しの間Rxを使用して、単一のアプリケーション内でイベントバス（CQRS / ESを考えてください）を作成してきましたが、それはうまく機能しているようです。ただし、さまざまなイベントソーシングフレームワークを調査した後、Rxが一度も使用されたことがありません。リフレクション/コンテナベースのディスパッチャとは対照的に、非常に適しているように見えますが、おそらく私が見逃しているものがあります。ショートッパーが3か月あるものにたくさんの時間を費やしたくないのですが、Rxが適切でない理由はありますか？
ありがとう、エリック
Rx は、イベント駆動型およびリアクティブプログラミング全般の素晴らしいフレームワークであることは間違いありません。実際、ディスパッチ用のインターフェースに制限することは、実際には、IObservableより重いものよりも優れた形式であると言えます。その場合、自然に「メッセージング」指向のスタイルを使用しているため、スケーリングと不変性に適しています。関心の分離が自然になります。
将来苦労する可能性があるのは、システムが単一のアプリケーションを超えて拡張される場合です。Rx は単一のアプリケーション内では非常に単純ですが、アプリケーション間に「インフラストラクチャ」を追加する必要があるとすぐに、いくらかの努力が必要になります。うまくいかないわけではありません！Subjectおよびインスタンスのさまざまなソースに接続すると、そうですIObservable-場合によっては手動で行う必要があるだけですが、他の「イベントソーシング」フレームワーク(何を念頭に置いていましたか?)には、より広い範囲の外部「アダプター」がある場合があります'。
一般的にこのように使用されている Rx について (つまり、インターネット上で)。まず、.NET 以外にも多くのプラットフォームがあり、Rx はそれらのいずれにも表示されないことを覚えておいてください。リアクティブなスタイルは、別の名前で呼ばれる可能性があります。
第二に、あなたは一人ではありません。CQRS で Rx が大好きな人を含めて、Scala と JVM でやりたいと思っています。
Rx のメッセージ バスの例を次に示します。
2 つのプロセス間で RX を使用する場合は、以下を確認してください。
これらのライブラリはすべて同じことを行っています。Microsoft の IObservable および IObserver インターフェイスを実装しています。
.NET で Rx をサポートするインメモリ バスを使用する場合は、MemBusを確認してください。
別の方法は、 ReactiveUIMessageBusから使用することです。ただし、専用のライブラリには同梱されていないため、ReactiveUI ライブラリ全体をインストールする必要があります。これは、WPF アプリケーションでのみ意味があり、従来の WinForms プロジェクトでは意味がありません。