1

この質問は、MediatR とデコレータを使用した DryIOC のセットアップに関する以前の質問のさらに別のフォローアップです: DryIOC と MediatR: IAsyncNotificationHandler と IAsyncRequestHandler の両方に InResolutionScopeOf を使用したインジェクション

この例では、セットアップは私の前の質問のものと似ています。リクエスト (IAsyncRequestHandler) と通知 (IAsyncNotificationHandler) があり、通知はリクエストから起動されており、両方が必要な DbContext に依存しています。解決スコープごとに注入されます。

私が今行っているのは IAsyncRequestHandler の装飾であり、キーを使用してタイプ IActionHandler の依存関係をデコレーターに渡しています。次のように依存関係を登録しています。

c.Register<IActionHandler, SomeActionHandler>(serviceKey: "key1");

そして、次のようにパラメーターをデコレーターに渡します。

c.Register(typeof(IAsyncRequestHandler<,>), typeof(Decorator<,>),
               made: Parameters.Of.Type<IActionHandler>(serviceKey: "key1"),
               setup: DryIoc.Setup.Decorator);

このように設定すると、通知はリクエスト ハンドラーから正常に発行されます。ただし、さらにデコレーターを追加し、デコレーターのセットアップ パラメーターを DecoratorWith に変更して条件を指定すると (単に true を返す場合でも)、DbContext が IAsyncNotificationHandler に正常に挿入されないため、リクエスト ハンドラーから通知が発生しません。 .

ここに問題を示すフィドルがありますhttps://dotnetfiddle.net/ob0nfA

デバッグ中に、2 つの登録がある場合、最初のデコレーターの DecoratorWith の条件が同じサービス タイプに対して 2 回呼び出されることがわかりました。これが意図されているかどうかはわかりませんが、問題に関連している可能性があると思います。単純に true を返すと、同じハンドラーに対して複数のデコレーターが登録されますが、1 つしか存在しないはずです。

代わりに Made を使用してデコレータの依存関係を登録できることはわかっていますが、この特定の例では、キー付きの登録が意図したセットアップに適しているようです。だから、私が欠けているものがあるかどうかを知りたい、またはDecoratorWithが同じサービスタイプに対して複数回呼び出されて意図したとおりに機能する場合、私ができる方法があるかどうか知りたい呼び出しを区別して、デコレータを一度だけ正しく登録できるようにします。あるいは、問題はまったく別の場所にあるのかもしれません。

ありがとう

4

1 に答える 1

0

理由が見つかりました。現在のDryIocバージョン2.9.3では、条件をデコレーターに追加すると、コンテキスト依存になります(これは本当です)。ただし、コンテキスト依存サービスは、式のインライン化ではなく解決呼び出しとして挿入されます。ここで解決呼び出しを使用すると、解決スコープが台無しになります (方法はまだ 100% 明確ではありません)。

したがって、コンテキスト依存デコレータの解決呼び出しへの切り替えを削除すると、コードが再び機能します。

修正は近日公開予定です。回答を修正バージョンで更新します。

修正を含む更新:

問題はDryIoc 2.9.5で修正されました

于 2016-12-10T13:00:02.990 に答える