Médiateur quand et pourquoi devrais-je l'utiliser? vs 2017 webapi
On l’a peut-être déjà demandé, mais je ne trouve même pas sur le site officiel pourquoi je devrais utiliser MediatR et quels problèmes il résout?
Est-ce parce que je peux passer un seul objet dans mon constructeur plutôt qu'une multitude d'interfaces?
Est-ce un remplacement ou un concurrent de ServicesBus etc ...
Fondamentalement, quels sont les avantages et quels problèmes résolvent-ils?
Je veux acheter, mais je ne comprends pas bien pourquoi je devrais l'utiliser.
merci beaucoup
Est-ce parce que je peux passer un seul objet dans mon constructeur plutôt que une multitude d'interfaces?
Non.
Est-ce un remplacement ou un concurrent de ServicesBus etc ...
Non.
Fondamentalement, quels sont les avantages et quels problèmes résolvent-ils?
Entre autres choses, l’un des problèmes que MediatR essaie de résoudre est Explosion du constructeur DI dans vos contrôleurs MVC
public DashboardController(
ICustomerRepository customerRepository,
IOrderService orderService,
ICustomerHistoryRepository historyRepository,
IOrderRepository orderRepository,
IProductRespoitory productRespoitory,
IRelatedProductsRepository relatedProductsRepository,
ISupportService supportService,
ILog logger
)
C'est un sujet très controversé et il n'y a pas de solution unique, jetez un oeil à cette question
Comment éviter la folie constructeur de l'injection de dépendance?
Si vous souhaitez masquer des dépendances derrière encore plus d'abstractions, vous voudrez alors examiner toutes les options, telles que la refactorisation, la séparation des problèmes un peu plus ou d'autres techniques.
En toute honnêteté, l’exemple de problème et de solution présenté sur le site Web {MediatR _ est un peu suspect, mais il a ses utilisations. En bref, vous devez choisir ce qui vous convient le mieux, à vous et à votre environnement.
Vue d'ensemble du motif médiateur
Un médiateur est un objet qui décide comment et quand les objets interagissent les uns avec les autres. Il encapsule le «comment» et coordonne l’exécution en fonction de l’état, de la façon dont elle est invoquée ou de la charge utile que vous lui fournissez.
Dans l'esprit de votre question, vous devriez vraiment regarder ce site.
Simplifier les problèmes de développement et de séparation avec MediatR
MediatR est une implémentation open source du motif médiateur qui n'essaie pas de faire trop et n'effectue aucune magie. Cela vous permet de composer des messages, créer et écouter des événements en utilisant synchrone ou modèles asynchrones. Cela aide à réduire le couplage et à isoler le préoccupations concernant la demande de travail à effectuer et la création du gestionnaire qui expédie le travail.
En savoir plus sur le motif Mediator
Pouvez-vous, à votre avis, décrire pourquoi vous l'utiliseriez?
Le modèle de médiateur aide dissocie votre application via la communication via un médiateur (c’est une chose).
Habituellement, un programme est composé d'un grand nombre de classes. Cependant, à mesure que de nouvelles classes sont ajoutées à un programme, le problème de la communication entre ces classes peut devenir plus complexe. Cela rend le programme plus difficile à lire et à maintenir. De plus, il peut devenir difficile de changer de programme, car tout changement peut affecter du code dans plusieurs autres classes.
Avec le modèle de médiateur, la communication entre les objets est encapsulée dans un objet médiateur. Les objets ne communiquent plus directement les uns avec les autres (découplage), mais au contraire via le médiateur. Cela réduit les dépendances entre les objets en communication, réduisant ainsi le couplage.
Dans les logiciels modernes, le motif médiateur se trouve généralement dans de nombreux frameworks. Vous pouvez toutefois créer le vôtre ou utiliser l'un des nombreux modèles disponibles.
À partir de là, je pense que vous devriez probablement simplement faire plus de recherches, je veux dire habituellement vous vous rendez compte que vous avez besoin de ces choses avant de les chercher, mais dans ce cas, je pense que vous devez vraiment trouver de bons exemples pour savoir si vous voulez le modèle de médiateur et plus encore La bibliothèque MediatR
Mettre à jour
(wired_in} _ a eu un bon commentaire pratique à ce sujet.
Tout ce que MediatR fait est de localiser un gestionnaire pour une demande. C'est pas le motif médiateur. Le "médiateur" dans ce cas ne le fait pas décrire comment deux objets communiquent, il utilise l'inversion de contrôle qui est déjà utilisé dans une application et fournit simplement un couche d'abstraction inutile qui ne sert qu'à faire une application plus difficile à raisonner dans son ensemble. Vous avez déjà réalisé le découplage de en utilisant une injection de constructeur standard avec IoC. Je ne comprends pas pourquoi les gens achètent dans cela. Créons plusieurs racines composites simplement pour que nous ne pas avoir à mettre des interfaces dans notre constructeur.
et
Le PO est tout à fait justifié de remettre en question le but de MediatR . Les principales réponses que j'entends à la question impliquent d'expliquer l'utilisation de le modèle de médiateur en général, ou qu'il crée le code appelant nettoyeur. La première explication suppose que la bibliothèque MediatR implémente réellement le modèle de médiateur, ce qui est loin d’être clair. Le ce dernier n’est pas une justification pour ajouter une autre abstraction au-dessus de un conteneur IoC déjà abstrait, qui crée plusieurs composites les racines. Il suffit d'injecter le gestionnaire au lieu du service qui le localise
C'est simplement un moyen d'implémenter la communication entre vos composants de logique métier.
Imaginez que vous avez:
FirstRequest // which handled by FirstRequestHandler(FirstRequest)
SecondRequest // which handled by SecondRequestHandler(SecondRequest)
ThirdRequest // which handled by ThirdRequestHandler(ThirdRequest)
... Il y en a des centaines ...
Et vient ensuite ComplexRequest, lorsque ComplexResponse doit être une combinaison de FirstResponse et ThirdResponse.
Comment devrions-nous résoudre ce problème?
Eh bien, ComplexRequestHandler devrait injecter FirstHandler et ThirdHandler, obtenir leurs résultats et les combiner.
Mais pourquoi ComplexRequestHandler devrait-il avoir accès à l'interface FirstRequestHandler? Pourquoi devrions-nous nous donner la peine d'injecter First, Third ... OneHundredAndTwentythHandler dans notre ComplexHandler?
Ce que MediatR nous donne dans un tel cas d’utilisation, c’est un tiers qui nous dit:
So ComplexHandler ne sait rien des First et Third Handlers. Il ne connaît que les requêtes et les réponses requises (qui ne font en général qu’emballer des DTO).
Remarque: vous n'êtes pas obligé d'utiliser la bibliothèque MediatR pour cela. Vous pouvez en savoir plus sur le modèle de médiateur et en implémenter un vous-même.