1

NServiceBus を v6 に移行する過程にあり、IBus への参照を削除する過程で障害があります。

多くのアプリケーション (Web サイト、マイクロ サービスなど) の共通ライブラリを構築します。このライブラリには、本質的に送信および公開インターフェイスである IEventPublisher の概念があります。このライブラリには NSB の知識がありません。次に、アプリケーションから DI を使用してこの IEventPublisher の実装を提供できます。これにより、ライブラリのメッセージ パッシングを別のテクノロジに簡単に置き換えることができます。

最終的には、次のような実装になります

public class NsbEventPublisher : IEventPublisher
{
    IEndpointInstance _instance;

    public NsbEventPublisher(IEndpointInstance endpoint)
    {
        instance = endpoint;
    }

    public void Send(object message)
    {
        instance.Send(message, sendOptions);
    }

    public void Publish(object message)
    {
        instance.Publish(message, sendOptions);
    }
}

これは実際に何が起こるかを単純化したものですが、私の問題を示しています。DI コンテナーが IEventPublisher を要求されると、NsbEventPublisher を返すことを認識し、Web サイトのブートストラップでこれをコンテナーにシングルトンとしてバインドするため、IEndpointInstance を解決することを認識します。すべて問題なく、私のサイトは完璧に動作します。

現在、マイクロ サービス (NSB.Host で実行) を移行していますが、メッセージ ハンドラー内の依存関係を解決するときに、DI コンテナーが IEndpointInstance の解決を拒否しています。ドキュメントを読むことは意図的なものであり、メッセージ ハンドラーでは IMessageHandlerContext を使用する必要があります。 https://docs.particular.net/nservicebus/upgrades/5to6/moving-away-from-ibus ドキュメントは、クラス MyContextAccessingDependency の周りの一番下の例で私が抱えている問題を回避しています。提案は、メッセージ ハンドラーのコンテキストで実行されているコードに強い依存関係を置くメソッドを介してメッセージ コンテキストを渡すことです。

私がやりたいことは、送信者/発行者にアクセスできることであり、DI コンテナーは正しい実装を提供してくれます。このコードは、呼び出し元の概念を必要とせず、メッセージ ハンドラーから呼び出された場合や、パブリッシュするだけの自己ホスト型アプリケーションから呼び出された場合も必要ありません。

IMessageHandlerContext および IEndpointInstance インターフェイスがそれぞれ拡張する「バス」 IPipelineContext および IMessageSession と通信するための 2 つのインターフェイスがあることがわかります。私が疑問に思っているのは、NSB によってコンテナーにバインドされる 2 つのインターフェースが統合されているため、メッセージを送信/公開するインターフェースを受け入れることができるということです。ハンドラーでは IMessageHandlerContext であり、自己ホスト型アプリケーションでは IEndPointInstance です。

今のところ、アプリケーションのホスティングに応じて IEventPublisher の実装を変更しようとしています。コードパスの実行を開始したものに関係なく、送信/公開するための信頼できるインターフェイスなしで、このアプローチをモデル化する方法についていくつかの議論があることを望んでいました.

4

1 に答える 1