私は新しい ASP.NET Core をいじっており、現在、JavaScript フロントエンドから呼び出したい API を作成しています。

結合を減らすためにメディエーター パターンを使用したいのですが、Jimmy BogardのライブラリMediatRを見つけました。

私の問題は、DI のビルドを使用して配線することにあります。サンプルを調べてみましたが、スタートアップ クラスの ConfigureServices メソッドにバインドする方法がわかりません。

誰か洞察力がありますか？

更新:私のConfigureServiceメソッドから、私はそれを機能させました:

MVVM フレームワークには Caliburn.Micro、IoC コンテナーには StructureMap、メディエーターの実装には MediatR を使用しています。MediatR イベント ハンドラーを登録するための推奨される方法が、ViewModels を独自のハンドラーとして使用する Caliburn.Micro の推奨されるアプローチとうまく機能しないことを除いて、これはすべて正常に機能します。

Caliburn.Micro は、EventAggregator を介してメディエーター パターンを実装します。これには、ViewModel に IEventAggregator を挿入し、それ自体にサブスクライブする (または IHandle<> インターフェイスを実装する何か) 必要があります。MediatR はより分離されたアプローチを採用しており、IRequestHandler<,> およびその他の型を閉じる型のアセンブリを反射的にスキャンすることをお勧めします。

私の問題は、StructureMap の経験不足だと思います。

私がやりたいのは、ViewModels 自体に Handler 機能を実装できるようにすることです (Caliburn.Micro が示唆するように) だけでなく、ViewModels が Caliburn.Micro のシングルトンとして登録されるようにすることもできます。

StructureMap が次のレジストリを処理する場合、RibbonMenuViewModel の 2 つのインスタンスがあります。1 つは Caliburn.Micro のシングルトン バージョンで、もう 1 つは MediatR INotificationHandler<> ジェネリック型を閉じる一時バージョンです。

StructureMap レジストリ

MediatR の INotificationHandler インスタンスとして Singleton ViewModel 登録を使用する最善の方法についてアドバイスをお願いします

参照用の Caliburn.Micro 構成は次のとおりです。

カリバーン ブートストラップの設定

複数の通知があり、タイプ IBusEvent のすべての通知に対して 1 つのハンドラー インスタンスのみが必要です。

これが私の現在の状況です

通知

ハンドラー

これらの通知の両方に対してハンドラーは 1 つしかありません。

IOC

必要なもの

この IOC レジストリを使用すると、IBusConfig ごとに BusEventHandler の 2 つのインスタンスを受け取ります。

IBusConfig ごとに BusEventHandler のインスタンスを 1 つだけ持つ必要があります。

良い動作を実現できる唯一の方法は、MediatorRegistry を変更することです

MediatorRegistry を変更せずにこれを達成するより良い方法はありませんか?

汎用インターフェイスをデコレータでラップしようとしていますが、単に機能しません。他の質問から、これを行う唯一の方法はデコレータごとに明示的に行うことだと思われます。私の質問はそれが可能かどうかです特定のインターフェイスを実装するすべてのタイプを ninject の特定の Decorator でラップします。

コード：

HTTP Get リクエストを送信した場合:

の内容を確認し、jsonOwinMiddlewareを使用している場所があります。contextpathIAsyncRequest<T>

どの非同期リクエストを使用するかを知るために、パスのマッピングがありTypeますIAsyncRequest<T>

を使用しJObjectて のインスタンスを作成しますGetCompanyRequest

私が使用する理由JObjectは、PUT および POST 要求の場合、JSON 本体を直接要求に逆シリアル化するためです。

object instantiatedRequestパズルの最後のピースは、メディエーター パイプラインを介してこれを送信しています。明らかTask<T> SendAsync<T>(IAsyncRequest<T> request)にうまくいきません。

興味深いことに、ユーザーにTポストバックするために常にシリアル化するため、知る必要はありません。string

では、これに対応するために署名Task<object> SendAsync(object request)を現在のメディエーター フレームワークに組み込むことはできますか? （求めているのではなく、可能ですか？）

ソースコードを見る

私はこれを見つけましたmediator.cs

その 2 番目GetHandlerには必要なパラメーターがあり、最初のパラメーターは によって呼び出されるSendAsyncものです。何かを貼り付けても問題はありません。

それを行うことに懸念はありますか？

CQRS パターンを使用して ASP.NET Core アプリケーションをセットアップしようとしています。これを達成するために、私はこれらのライブラリを使用しています:

必要な設定をすべて実行し、Mediatr が機能し、依存性注入が機能しましたが、コードはハンドラーに行く前に検証を通過しません。検証デコレータの登録に問題があると思います。私が使用しているほとんどのライブラリは最近更新され、ASP.NET Core をサポートするために大幅に変更されたためです。構成で何が欠けていますか? それがどうあるべきか？

私の構成

MediatorPipeline (本当に必要かどうかはわかりません。)

ValidatorHandler

GetUserByEmailQuery.cs

このクラスでは、私のコードは public UserDomain Handle(GetUserByEmailQuery message)検証を行わずに直接入ります。

MediatR複雑な Web コントローラーをクリーンアップするためのテストを開始したところです。機能自体を実装することはまったく難しくありませんが、テストには少し苦労しています。

注文をキャンセルするためのコントローラーメソッドから始めました。

注文がキャンセルされた場合、

• データベース内のデータに「キャンセル済み」フラグを設定する
• 誰が会議をキャンセルしたかを監査ログに記録する
• 一部のスーパーバイザーに電子メールで通知を送信します。

これらはすべてコントローラー メソッド内でトリガーされ、コントローラーは複数の異なるサービスに依存していました。テストするときは、各パーツをモックして、テストしたい動作を分離する必要がありました。

これを実装する方法は、コントローラー メソッドから -query を発行することでしたMediatR。CancelOrder次にCancelOrderHandler、「キャンセル済み」フラグの保管を担当する を作成しました。

カスタムMediatorPipeline実装を使用して、例外がスローされないOrderCancelled場合は通知を発行します。CancelOrderHandler

この通知には、 と の 2 つのハンドラーがOrderCancelledAuditLogHandlerありOrderCancelledNotificationHandlerます。1 つ目は監査ログを処理し、2 つ目は通知を送信します。

各ハンドラは簡単にテストできます。しかし、すべてが「ぴったり合っている」ことをどのようにテストできますか? 注文がキャンセルされたときに、監査ログと通知が実際に処理されるようにしたいと考えています。すべてのハンドラーは、テストの実行中に私が本当に望んでいないこと (データベースの書き込みと電子メールの送信) を実行し、本格的なエンドツーエンドの統合テストには熱心ではありません。

何か案は？