問題タブ [mediatr]

データ アクセスに Entity Framework を使用する WinForms アプリケーションでMediatRライブラリを使用して、メディエーター パターンと CQRS を試してきました。このアプリケーションはバッチ製造プラントで使用され、ユーザーはアクティブなバッチと完了したバッチのリストを表示し、必要に応じてバッチ情報を更新できます。各バッチには、品質やプロセスの測定値など、大量の情報が関連付けられています。データの読み取りと書き込みは、次の記事に基づいてクエリとコマンドにまとめられています。

その間...私のアーキテクチャのクエリ側で

MediatR と AutoMapper を使用した CQRS

クエリとクエリ ハンドラの簡単な例を次に示します。DataContextSimpleInjector を使用してクエリ ハンドラに挿入されます。

これは、次のようにプレゼンターから呼び出されます。

私が直面している問題は、DbContext の有効期間にあります。理想的には、分離されたトランザクションごとに 1 つのインスタンスを使用したいと考えています。この場合、次のようなものが含まれます。

• データベースからバッチのリストを取得する
• バッチの品質指標のリストを取得する (これらは別のデータベースに保存され、ストアド プロシージャを介してアクセスされます)
• データベース内の複数のエンティティの更新を含む場合があるバッチの更新

これにより、DbContext のスコープ付きまたは一時的なライフスタイルに向かうことになります。ただし、一時的なライフスタイルを使用する場合、SimpleInjector は次のエラーを発生させます。これは、次のように型を登録するときにスローされます。

SimpleInjector.dll でタイプ 'SimpleInjector.DiagnosticVerificationException' の未処理の例外が発生しました

追加情報: 構成が無効です。次の診断警告が報告されました。

-[Disposable Transient Component] DataContextはtransientとして登録されていますが、IDisposableを実装しています。

SimpleInjector Web サイトでこの問題を調査すると、次のメモが明らかになります。

警告: 一時インスタンスはコンテナーによって追跡されません。これは、Simple Injector が一時的なインスタンスを破棄しないことを意味します。

これにより、DataContext に Lifetime Scope ライフスタイルを使用する道に進みました。これを実現するために、クエリ用の新しいデコレータ クラスを作成し、次のように登録しました。

ただし、その変更を行うと別の例外が発生し、今回は次の行でスローされます。

MediatR.dll で 'System.InvalidOperationException' 型の未処理の例外が発生しました

追加情報: タイプ MediatorTest.GetAllBatchesQuery の要求のハンドラーが見つかりませんでした。

コンテナーまたはサービス ロケーターが正しく構成されていないか、コンテナーにハンドラーが登録されていません。

デバッグして MediatR コードを調べると、メソッドが呼び出されると、を呼び出すことによってクラスmediator.Send(...)の新しいインスタンスが作成されることがわかります。ただし、この時点では実行スコープ内にないため、適切に初期化されず、例外が発生する可能性があります。GetAllBatchesQueryHandlercontainer.GetInstance()DataContext

問題の根本原因は理解できたと思いますが、効果的に解決する方法がわかりません。この問題をよりよく説明するために、次の最小限の例を作成しました。実装するクラスはすべてIDisposable、私が抱えているのと同じ問題を引き起こしますDataContext。

LightInject と MediatR を使用して汎用リクエスト ハンドラーを作成しようとしています。基本的に、次のようなタイプがあります。

そしてHandler、次のように自分の型を LightInject コンテナに登録しました。

しかし、メディエーターを呼び出して の実装を試みると、IAsyncRequestHandler<InheritedType,SomeResponseType>失敗します。実装Handler以来、登録を取得することを期待していたでしょう。InheritedTypeSomeType

ここで何か間違ったことをしていますか、または上記の動作を LightInject で実現する方法はありますか?

不明な点がある場合はお知らせください。詳しい情報を提供できるよう努めます。ありがとう！

MediatR を使用して、視覚化Dto を要求しています

これらは から直接マップされますDbContext。問題は、ProjectToList<>再帰的にマップすることです。レベルにはバッファのリストがあり、各バッファにはスタックのリストがあります。これで、TimeOut 値が null のスタックをマップするだけで済みます。マッピングが遅くなる可能性があるため、マッピング後にすべてをフィルター処理したくありません。そして、私は試しました

しかし、私が受け取る値はフィルタリングされたものではなく、完全なデータセットです。でフィルタリングする他の方法はありますProjectToListか?

今、私は次のような出力を持っています

既に終了しているスタックを除外して、TimeOut が null でないスタックを除外する必要があります。

コントローラ

Get() アクションの最初の要求で、Handler は SimpleInjector によってインスタンス化され、正しく実行されます。

2 番目のリクエスト (ブラウザで F5 キーなど) では、次のエラーで失敗します。

タイプ .... のリクエストのハンドラーが見つかりませんでした。

コンテナーまたはサービス ロケーターが正しく構成されていないか、コンテナーにハンドラーが登録されていません。

および内部例外:

破棄されたオブジェクトにアクセスできません。

オブジェクト名: 「ThreadLocal オブジェクトは破棄されました。」

OWIN スタートアップ

WebAPI プロジェクトの SimpleInjector IPackage

ハンドラーが正しく作成され、最初のリクエストの後に破棄されていると思います。理由はわかりませんが、後続のリクエストで Handler が再作成されません。WebApiRequestLifestyle を「スコープの終了時に破棄しない」に変更すると、すべてのリクエストで機能するため、これを知っています。

質問

1. disposeInstanceWhenScopeEndsパラメータを false に設定しておく必要がありますか?
2. そうでない場合、正しい解決策は何ですか？
3. これはLifetimeScopeDecorator を作成することで以前に解決されているようですが、この機能は SimpleInjector WebApi 統合ライブラリによって既に提供されているのでしょうか? 私は何が欠けていますか？

(そして読んでくれてありがとう)

Autofac 3.5 と MediatR を使用して、特定のインターフェイスを実装する閉じた型にデコレータを適用しようとしています。次のハンドラータイプがあります。

そして、IRequestHandler<,> を実装するすべての型に、次の一般的なオープン デコレータ型を適用したいと思います。

私のAutofac構成は次のとおりです。

閉じた型は注入されますが、LoggingHandler で装飾されることはありません。ここで何が欠けているのかわかりません。Autofac でのオープン ジェネリック登録のためにオープン ジェネリック デコレータを登録する方法は?に従っていくつかのアプローチを試しました。またはAutoFac - 開いている Generic の一部にデコレータを登録しますが、どれもうまくいきません。

I'm trying to use FluentValidation in a WebApi project (not asp.net Core).

I have the following code:

I'm scanning the assemblies and registrering the validators, of which there's only one right now, it sits here: (don't mind the weird validations, I'm trying to have it fail)

My Application_start looks like this:

And I have the following validatorFactory:

Now; when I call the action on the controller, 'CreateInstance' tries to resolve a validatorType of the type:

instead of:

and of course finds nothing, this means that my validations does not run.

Does anyone have an ideas as to why this is? it seems faily straight forward, so I have trouble seeing what goes wrong.

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

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

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

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

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

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

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

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

ありがとう