2

ここ数日、私が気になっている話題について、あなたの意見を聞きたい..

私たちのプロジェクトでは、MassTransit サービス バスを使用しています。IoC コンテナーを使用して IServiceBus (MassTransit のインターフェイス) のシングルトン インスタンスを作成し、この IServiceBus を必要とするすべてのクラスがコンストラクターでそれを取得します。これにより、私たちのプロジェクトの多くのクラスがコンストラクター パラメーターとして IServiceBus を取得し、MassTransit サービス バスと結合され、実際にはメッセージ キューを使用した通知の概念に結合されます。

カップリングの悪い例だと思います。

IServiceBus をさまざまなクラスに渡すことで、このクラスが外部リスナーに通知を送信する方法を定義し、その方法を強制的にサービス バス指向の方法にします。

.NET の従来の方法の方が優れていると思います。クラスは、.NET イベント ハンドラーとのインターフェイスでイベントを定義する必要があり、このイベント ハンドラーを使用するオブザーバーはそれにサブスクライブする必要があります。

そのようにして得られるのは、サービス バスを使用したクラスの実装にコミットしていないということです。これにより、サービス バスはそのクラス イベント ハンドラーのオブザーバーになり、そのイベントが発生すると、サービス バス キューにメッセージを送信するロジックが発生します。

これも大きな疑問です..

プロジェクトが単一のプロセスで実行される場合、プロジェクトでサービス バスを使用する必要があるのはいつ、どのような場合ですか?

プロジェクトが複数のプロセスで構成されている場合、メッセージ キューを使用して厳密に型指定されたメッセージを渡す方が簡単であるため、利点を確認できますが、1 つのプロセス スコープ内にある場合の利点は理解できません。クラスがオブザーバーやコンシューマーなどに通知を通知するようにしたい場合は、クラス内からイベントを発生させ、プロジェクト内のこれらすべてのイベントをサブスクライブする単一またはクローズド グループのディスパッチャー クラスを作成します。メッセージ転送のロジック。また、そのようにしてオブザーバーを追加するロジックは、プロジェクト内の 1 つの場所に集中します。

この件についてのご意見をお聞かせいただければ幸いです..

4

1 に答える 1

0

これは本当に素晴らしいSOの質問ではありません。閉店しそうです。あなたの質問に関係なく、 の表面積IServiceBusはかなり小さいです。必要に応じて簡単に交換できます。インターフェースを実装すると、消費者はより結合されConsumes.*ます。ただし、コンシューマーをデリゲートとして登録するだけで問題ありません。最終結果は、システム全体の結合が少なくなるはずです。

最後に、サービス バスを使用するので、メッセージの転送や配信について心配する必要はありません。プロセス内通信は実際には問題にならない場合もありますが、将来的には簡単にばらばらになります。

于 2013-08-16T11:52:18.083 に答える