web-dev-qa-db-ja.com

MediatRを使用するタイミングと理由vs 2017 webapi

以前に尋ねられたかもしれませんが、公式サイトでもMediatRを使用する理由とそれが解決する問題を見つけることができませんか？

  • それは、多数のインターフェイスではなく、コンストラクターで単一のオブジェクトを渡すことができるからですか？

  • ServicesBusなどの代替品または競合品ですか？.

  • 基本的にどのような利点があり、どのような問題を解決しますか

私はそれに買いたいと思うが、なぜそれを使用するべきか私にははっきりしない。

どうもありがとう

c#asp.net-core-webapiarchitectural-patterns
49
developer9969

それは、多数のインターフェイスではなく、コンストラクタで単一のオブジェクトを渡すことができるからですか？

番号。

ServicesBusなどの代替品または競合品ですか？.

番号。

基本的にどのような利点があり、どのような問題が解決しますか

とりわけ、MediatRが解決しようとしている問題の1つは、MVCコントローラーのDIコンストラクター爆発です。

public DashboardController(
    ICustomerRepository customerRepository,
    IOrderService orderService,
    ICustomerHistoryRepository historyRepository,
    IOrderRepository orderRepository,
    IProductRespoitory productRespoitory,
    IRelatedProductsRepository relatedProductsRepository,
    ISupportService supportService,
    ILog logger
    )

これは非常に議論されているトピックであり、万能のソリューションはありません。この質問を見てください

依存性注入コンストラクターの狂気を避ける方法

さらに多くの抽象化の背後に依存関係を隠したい場合は、この時点で、リファクタリング、懸念の分離、またはその他の手法など、すべてのオプションを確認する必要があります。

正直なところ、MediatR Webサイトに記載されている問題と解決策の例は、少し疑わしいですが、用途はあります 。つまり、あなたとあなたの環境に合ったものを選択する必要があります。

メディエーターパターンの概要

メディエーターは、オブジェクトが相互作用する方法とタイミングを決定するオブジェクトです。 「方法」をカプセル化し、状態、起動方法、または提供するペイロードに基づいて実行を調整します。

あなたの質問の精神に関しては、あなたは本当にこのサイトを見るべきです：

MediatRによる開発の簡素化と懸念の分離

MediatRはメディエーターパターンのオープンソース実装であり、あまり多くのことをしようとせず、魔法をかけません。同期または非同期パターンを使用して、メッセージを作成し、イベントを作成してリッスンできます。結合を減らし、作業の実行を要求し、作業をディスパッチするハンドラーを作成することの懸念を分離するのに役立ちます。

メディエーターパターンの詳細

あなたはそれを使用する理由をあなた自身の意見で説明できますか

メディエーターパターンは、 デカップリング メディエーターを介した通信を介したアプリケーション（そのこと）に役立ちます。

通常、プログラムは多数のクラスで構成されます。ただし、プログラムにクラスが追加されると、これらのクラス間の通信の問題はより複雑になる可能性があります。これにより、プログラムの読み取りと保守が難しくなります。さらに、プログラムを変更することは、他のいくつかのクラスのコードに影響を与える可能性があるため、困難になる可能性があります。

メディエーターパターンを使用すると、オブジェクト間の通信はメディエーターオブジェクト内にカプセル化されます。オブジェクトは互いに直接通信しなくなり（分離）、代わりにメディエーターを介して通信します。これにより、通信するオブジェクト間の依存関係が減少し、それにより結合が減少します。

最新のソフトウェアでは、メディエーターパターンは通常多くのフレームワーク内にありますが、独自のフレームワークを作成するか、使用可能な多くのフレームワークの1つを使用できます。

ここから、あなたはおそらくもっと研究する必要があると思う、私は通常あなたがそれらを研究する前にあなたがこれらのものを必要とすることを理解することを意味するが、この場合私はあなたがメディエーターパターンを望むかどうかを知るためにいくつかの良い例を見つける必要があると思う、さらにMediatRライブラリ

更新

wired_inこれについていくつかの素晴らしい実用的なコメントがありました

MediatRが行うことは、リクエストのハンドラーをサービス検索することだけです。それはメディエーターパターンではありません。このインスタンスの「メディエーター」は、2つのオブジェクトがどのように通信するかを説明せず、アプリケーションで既に使用されている制御の反転を使用し、アプリケーションの推論を難しくする役目だけを果たす役に立たない抽象化レイヤーを提供します全体。 IoCで標準のコンストラクター注入を使用することで、すでに分離を実現しています。なぜ人々がこれを買うのか分かりません。コンストラクターにインターフェイスを配置する必要がないように、複数の複合ルートを作成しましょう。

そして

OPはMediatRのポイントに疑問を呈することで完全に正当化されます。私が質問に対してよく耳にする回答には、メディエーターパターンの一般的な使用方法の説明、または呼び出し元のコードをクリーンにするというものがあります。前者の説明は、MediatRライブラリーがメディエーターパターンを実際に実装していることを前提としていますが、これは明らかではありません。後者は、すでに抽象化されたIoCコンテナの上に別の抽象化を追加する正当な理由ではなく、複数の複合ルートを作成します。サービスの場所を特定する代わりに、ハンドラを挿入するだけです

54
TheGeneral

これは、ビジネスロジックコンポーネント間の通信を実装する方法にすぎません。

あなたが持っていると想像してください：

FirstRequest // which handled by FirstRequestHandler(FirstRequest)
SecondRequest // which handled by SecondRequestHandler(SecondRequest)
ThirdRequest // which handled by ThirdRequestHandler(ThirdRequest)

...何百もあります...

そして、ComplexResponseがFirstResponseとThirdResponseの組み合わせである必要があるときに、ComplexRequestが登場します。

これをどのように解決する必要がありますか？

まあ、ComplexRequestHandlerはFirstHandlerとThirdHandlerを注入し、結果を取得し、それらを結合する必要があります。

しかし、なぜComplexRequestHandlerはFirstRequestHandlerインターフェースにアクセスする必要があるのでしょうか？なぜ最初、3番目... OneHundredAndTwentythHandlerをComplexHandlerに注入する必要があるのですか？

このようなユースケースでMediatRが提供するのは、「リクエストをください。正しい応答を受け取ります、信頼してください」というサードパーティです。

したがって、ComplexHandlerは第1および第3ハンドラーについて何も知りません。必要な要求と応答（通常は単にDTOをラップするだけです）についてのみ知っています。

注：そのために必ずしもMediatRライブラリを使用する必要はありません。 Mediatorパターンについて読んで、自分で実装することができます。

5
Holtz Ilya