MediatR, когда и почему я должен его использовать? vs 2017 webapi

Ответ 1

Это потому, что я могу передать один объект в моем конструкторе, а не множество интерфейсов?

Нет.

Это замена или конкурент ServicesBus и т. Д...

Нет.

Каковы преимущества и какие проблемы они решают?

Среди прочего, одна из проблем, которую MediatR пытается решить, - это DI Constructor Explosion в ваших контроллерах MVC

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

Это очень обсуждаемая тема, и не существует универсального решения, взгляните на этот вопрос

Как избежать сумасшествия конструктора Dependency Injection?

Если вы хотите скрыть зависимости за еще большим количеством абстракций, то на этом этапе вы захотите взглянуть на все параметры, такие как рефакторинг, разделение проблем или другие методы.

Честно говоря, примерная проблема и решение, приведенные на веб-сайте MediatR, немного подозрительны, однако у них есть свои применения. Короче говоря, вам нужно выбрать то, что подходит именно вам и вашей среде.

Обзор паттерна посредника

Посредник - это объект, который принимает решения о том, как и когда объекты взаимодействуют друг с другом. Он инкапсулирует "как" и координирует выполнение на основе состояния, способа его вызова или полезной нагрузки, которую вы ему предоставляете.

Что касается духа вашего вопроса, вы действительно должны взглянуть на этот сайт:

Упрощение разработки и разделения проблем с MediatR

MediatR - это реализация шаблона посредника с открытым исходным кодом, который не пытается делать слишком много и не выполняет никаких действий. Это позволяет вам составлять сообщения, создавать и прослушивать события, используя синхронные или асинхронные шаблоны. Это помогает уменьшить связь и изолировать проблемы, связанные с запросом выполняемой работы и созданием обработчика, который отправляет работу.

Подробнее о схеме посредника

Можете ли вы, по вашему мнению, описать, почему вы бы это использовали?

Шаблон посредника помогает отделить ваше приложение от общения через посредника (это вещь).

Обычно программа состоит из большого количества классов. Однако по мере того, как в программу добавляется больше классов, проблема связи между этими классами может стать более сложной. Это затрудняет чтение и обслуживание программы. Кроме того, изменение программы может оказаться затруднительным, поскольку любое изменение может повлиять на код в нескольких других классах.

При использовании шаблона посредника связь между объектами инкапсулируется в объекте-посреднике. Объекты больше не общаются напрямую друг с другом (разъединение), а вместо этого общаются через посредника. Это уменьшает зависимости между взаимодействующими объектами, тем самым уменьшая связь.

В современном программном обеспечении шаблон-посредник обычно встречается во многих средах, однако вы можете создать свой собственный или использовать один из многих доступных.

Отсюда, я думаю, вам, вероятно, стоит просто провести больше исследований, я имею в виду, что обычно вы выясняете, что вам нужны эти вещи, прежде чем исследовать их, однако в этом случае я думаю, что вам действительно нужно найти несколько хороших примеров, чтобы узнать, хотите ли вы паттерн посредника и даже больше Библиотека MediatR

Обновить

У wired_in был отличный практический комментарий

Все, что делает MediatR, - это служба поиска обработчика для запроса. Это не образец посредника. "Посредник" в данном случае не описывает, как взаимодействуют два объекта, он использует инверсию управления, которая уже используется в приложении, и просто обеспечивает бесполезный уровень абстракции, который только усложняет задачу приложения как рассуждения как все. Вы уже достигли развязки с помощью стандартного инжектора конструктора с IoC. Я не понимаю, почему люди покупают это. Давайте создадим несколько составных корней просто для того, чтобы нам не пришлось помещать интерфейсы в наш конструктор.

а также

ОП полностью оправдан в вопросе о MediatR. Лучшие ответы, которые я слышу на этот вопрос, включают объяснение использования шаблона-посредника в целом или того, как он делает код вызова более чистым. В первом объяснении предполагается, что библиотека MediatR фактически реализует шаблон посредника, что далеко не ясно. Последнее не является оправданием для добавления другой абстракции поверх уже абстрагированного контейнера IoC, который создает несколько составных корней. Просто внедрите обработчик вместо службы, находящей его

Ответ 2

Это просто способ реализовать связь между вашими компонентами бизнес-логики.

Представь, что у тебя есть:

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

... их сотни...

И тогда прибывает ComplexRequest, когда ComplexResponse должен быть комбинацией FirstResponse и ThirdResponse.

Как мы должны решить это?

Что ж, ComplexRequestHandler должен будет ввести FirstHandler и ThirdHandler, получить их результаты и объединить их.

Но почему ComplexRequestHandler должен иметь доступ к интерфейсу FirstRequestHandler? Почему мы должны потрудиться внедрить First, Third... OneHundredAndthththHandler в наш ComplexHandler?

Что MediatR дает нам в таком случае использования, это третье лицо, которое говорит нам: "Дайте мне запрос, и я получу правильный ответ, поверьте мне!"

Таким образом, ComplexHandler ничего не знает о первом и третьем обработчиках. Он знает только о требуемых запросах и ответах (которые, как правило, являются всего лишь оболочкой DTO).

Примечание. Для этого необязательно использовать библиотеку MediatR. Вы можете прочитать о модели посредника и реализовать ее самостоятельно.