Почти везде я вижу примеры, где команды и Запросы обрабатываются MediatR, но я не вижу в этом никакой пользы, кроме отсутствия необходимости регистрировать каждую команду или запрос в контейнере внедрения зависимостей. Но затем вам необходимо реализовать объекты Query (наследующие IRequest), объекты Query Handlers и Query Responses, чтобы в вашем методе контроллера API вы могли затем вызвать _mediatr.Send(queryObject).
Почему бы просто не использовать внедрение зависимостей для внедрения объекта запроса в контроллер API, на котором вы можете напрямую вызывать методы «get»? Нравится:
Код: Выделить всё
[HttpGet]
[Route("getall")]
public async Task GetAll(int page = 0, int pageSize = 25)
{
var result = await _incidentQueries.GetIncidents(page, pageSize);
return result;
}
Код: Выделить всё
[HttpGet]
[Route("getall")]
public async Task GetAll(int page = 0, int pageSize = 25)
{
var query = new IncidentQuery(page, pageSize);
var result = await _mediatr.Send(query);
return result;
}
Для меня идеальное и единственно разумное использование библиотеки MediatR — это обработка событий домена.
При реализации DDD я Я пытаюсь создать проект, как показано ниже. Каждый прямоугольник представляет собой отдельный проект в решении. Стрелки обозначают ссылки:
Представим себе сценарий: для создания объекта домена необходимо увеличить счетчик, хранящийся в другом объекте домена (другой агрегат).
- Запрос создается для конечной точки API для добавления нового объекта домена в базу данных (уровень 6: презентация)
- Метод контроллера использует команду, внедренную в его конструктор, для создания объект домена (уровень 4: Команды)
- Внутри команды создается новый объект домена вместе с событием «объект создан», хранящимся в этом объекте, готовый будет транслироваться непосредственно перед сохранением в базу данных.
- Затем команда использует репозиторий из уровня инфраструктуры, чтобы добавить этот вновь созданный объект в базу данных.
- Затем непосредственно перед выполняется сохранение базы данных: событие «создание объекта домена» отправляется через MediatR (уровень 2: инфраструктура)
- Затем событие перехватывается на слое 3: Приложение в одном из обработчиков событий домена.
- Обработчик событий домена (уровень 3: Приложение) использует репозиторий из уровня инфраструктуры для получения другой домен. Агрегат содержит счетчик, который необходимо увеличить, а затем увеличивает счетчик.
- Все события домена обработаны, выполняется сохранение в базу данных.
Люди просто используют MediatR для команд и запросов только ради их использования? На мой взгляд, добавление команд и обработчиков запросов, запросов и типов команд и ответов только добавляет больше кода, который не имеет реальной ценности, и только делает его менее понятным.
Вот несколько ссылок, которые я посетил:
- https://referbruv.com/blog/posts/implem ... -explained
https://www.edument.se/en/blog/post/net ... diatr-cqrs - https:// itnext.io/why-and-how-i-implemented-cqrs-and-mediator-patterns-in-a-microservice-b07034592b6d
- https://www.rubicon-world. com/blog/2020/06/a-developers-guide-to-cqrs-using-net-core-and-mediatr/
- https://dotnetdetail.net/cqrs-and -mediator-patterns-in-asp-net-core-3-1/
Из-за слишком большого количества обработчиков в вашем приложении сложно понять, что делает ваше приложение и что инициирует. Я увидел, что люди обрабатывают события домена на уровне команд, но домен, вероятно, не должен отправлять команды напрямую?
Нужно ли вообще использовать MediatR в CQRS?
Подробнее здесь: https://stackoverflow.com/questions/665 ... on-the-web
