MediatRはいつ、なぜ使うべきですか？[クローズド］

質問

以前にも質問されたことがあるかもしれませんが、なぜMediatRを使うべきなのか、どんな問題を解決してくれるのか、公式サイトでも見当たりません。

• 多数のInterfacesではなく、単一のオブジェクトをコンストラクタに渡すことができるからでしょうか。

• ServicesBusなどの代替品、競合品なのでしょうか...。

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

購入したいが、なぜそれを使わなければならないのかが明確でない。

ありがとうございます。

どのように解決するのですか？

<ブロッククオート

コンストラクタに単一のオブジェクトを渡すことができるためでしょうか。 を渡すことができるからでしょうか？

いいえ。

<ブロッククオート

ServicesBusなどの代わりなのか、競合なのか...。

いいえ。

<ブロッククオート

基本的にどんな利点があり、どんな問題を解決するのか。

---

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

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

これは非常に議論の多いテーマで、万能な解決策はありません。この質問を見てください。

依存性注入のコンストラクタの狂気を回避する方法は？

依存性をより抽象化したものに隠したいのであれば、この時点で、リファクタリング、懸念事項をもう少し分離する、あるいは他のテクニックなど、あらゆる選択肢を検討したいと思うことでしょう。

正直なところ、このページで紹介されている問題と解決策は MediatR のサイトで示されている例の問題と解決策は、少し疑わしいものです。 しかし、それはその用途を持っています . 要するに、自分と自分の環境に合ったものを選ぶ必要があるのです。

Mediatorパターンの概要

Mediatorは、オブジェクトがいつ、どのように相互作用するかを決定するオブジェクトです。どのように」をカプセル化し、状態や起動方法、ペイロードに基づいて実行を調整します。

あなたの質問の精神に関して、あなたは本当にこのサイトを見ている必要があります。

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

<ブロッククオート

MediatRはオープンソースのMediatorパターンの実装です。 MediatRはオープンソースのMediatorパターンの実装で、あまり多くのことをやろうとせず、魔法も使いません。このパターンでは、以下のことが可能です。 メッセージの作成、イベントの作成、イベントのリッスンを同期または非同期で行うことができます。 非同期パターン 結合を減らし、実行される作業の要求に関する懸念を分離するのに役立ちます。 また、結合を減らし、実行される作業の要求と、その作業をディスパッチするハンドラの作成という問題を分離することができます。 を作成するという作業を分離することができます。

Mediatorパターンの詳細

<ブロッククオート

あなた自身の意見として、なぜそれを使うのかを説明してもらえますか？

Mediatorパターンは デカップリング Mediatorを介した通信により、アプリケーションをデカップリングすることができます（そのこと）。

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

Mediator パターンでは、オブジェクト間の通信を Mediator オブジェクトにカプセル化します。オブジェクト同士が直接通信する（デカップリング）ことはなく、Mediatorを介した通信となります。これにより、通信を行うオブジェクト間の依存関係が緩和され、カップリングが低減されます。

最近のソフトウェアでは、mediatorパターンは多くのフレームワークの中に含まれていますが、自分で作ることもできますし、利用可能な多くのフレームワークの中から1つを使うこともできます。

ここから、私は、あなたはおそらくもっと研究をするべきだと思います。つまり、通常、あなたはそれらを研究する前にこれらのものが必要であることを理解しますが、このケースでは、あなたがMediatorパターンを必要とするかどうかを知るために、いくつかの良い例を見つける必要があると思います。 MediatR ライブラリ

更新

ワイヤードイン は、この件に関して素晴らしい実用的なコメントをしています。

<ブロッククオート

MediatRが行うのは、リクエストに対するハンドラを探すサービスだけです。それは mediatorのパターンではありません。この例では、quot;mediator" は、2つのオブジェクトがどのように通信するかを記述していません。 2つのオブジェクトがどのように通信するかを記述するものではなく、アプリケーションで既に使われている制御の逆転を使うものです。 を使うだけです。 アプリケーションを抽象化する無駄なレイヤーを提供するだけです。 アプリケーションを難しくしてしまうだけです。デカップリングはすでに以下の方法で実現されています。 標準的なコンストラクタ注入とIoCを使うことで、すでにデカップリングを実現しています。私は、なぜ を買うのか理解できない。コンポジットルートを複数作成しましょう。 コンストラクタにインターフェイスを記述する必要がないように、複数の複合根を作成しましょう。

と

OPがMediatRのポイントに疑問を持つのは完全に正当なことです。 この質問に対する回答は、mediatatorパターンの使用法全般を説明するものばかりです。 Mediatatorパターンの使い方を説明したり、呼び出し側のコードをよりきれいにするため といった答えが返ってきます。前者はMediatRライブラリが実際にmediatorパターンを実装していることを前提にした説明です。 が実際にmediatorパターンを実装していることを前提にしていますが、これは明確ではありません。後者は 後者は、すでに抽象化されたIoCコンテナの上に別の抽象化を追加する正当な理由にはならない。 を追加する正当な理由にはなりません。 のルートになります。サービスロケートする代わりにハンドラをインジェクトするだけです。