День 2246. #ЗаметкиНаПолях
Не Смешивайте CQRS и MediatR. Начало
Экосистема .NET постепенно приравняла CQRS к использованию MediatR. Развеем некоторые распространённые заблуждения и выделим преимущества каждого шаблона.
CQRS в чистом виде
CQRS — это паттерн, разделяющий операции чтения и записи в приложении. Он предполагает, что модели, используемые для чтения данных, должны отличаться от моделей, используемых для записи. Никаких конкретных деталей реализации, никаких предписанных библиотек, просто архитектурный принцип.
Он возник из понимания того, что во многих приложениях, особенно в сложных доменах, требования к чтению и записи данных принципиально различаются. Операции чтения часто требуют объединения данных из нескольких источников или представления их в определённых форматах для UI. Операции записи должны обеспечивать соблюдение бизнес-правил, поддерживать согласованность и управлять состоянием домена.
Такое разделение даёт несколько преимуществ:
1. Оптимизированные модели чтения и записи для их конкретных целей.
2. Упрощённое обслуживание, поскольку проблемы чтения и записи независимы.
3. Расширенные возможности масштабирования для операций чтения и записи.
4. Более чёткая граница между логикой предметной области и потребностями представления.
MediatR
MediatR — это реализация шаблона посредника. Его основная цель — уменьшить прямые зависимости между компонентами, предоставляя единую точку связи. Вместо того, чтобы компоненты знали друг о друге, используется посредник, который их соединяет.
MediatR предоставляет несколько функций:
1. Внутрипроцессный обмен сообщениями между компонентами.
2. Поведения конвейера (pipeline behaviors) для сквозных проблем.
3. Обработка уведомлений (по модели публикация/подписка).
Косвенность, которую вводит MediatR, является его наиболее критикуемым аспектом. Она может усложнить отслеживание кода, особенно для новичков. Однако можно решить эту проблему, определив запросы в том же файле, что и обработчики.
Почему они часто появляются вместе?
Частое сочетание CQRS и MediatR не беспричинно. Модель запроса/ответа MediatR хорошо согласуется с разделением команд/запросов в CQRS. Команды и запросы могут быть реализованы как запросы MediatR, с обработчиками, содержащими фактическую логику реализации.
Вот пример команды в MediatR:
public record CreateHabit(string Name, string? Description, int Priority) : IRequest<HabitDto>;
public sealed class CreateHabitHandler(
ApplicationDbContext dbContext,
IValidator<CreateHabit> validator)
: IRequestHandler<CreateHabit, HabitDto>
{
public async Task<HabitDto> Handle(
CreateHabit request, CancellationToken ct)
{
await validator
.ValidateAndThrowAsync(request);
var habit = request.ToEntity();
dbContext.Habits.Add(habit);
await dbContext.SaveChangesAsync(ct);
return habit.ToDto();
}
}
CQRS с MediatR предлагает несколько преимуществ:
1. Согласованная обработка как команд, так и запросов.
2. Поведения конвейера для регистрации, проверки и обработки ошибок.
3. Чёткое разделение проблем с помощью классов обработчиков.
4. Упрощённое тестирование с помощью изоляции обработчиков.
Однако это удобство достигается ценой дополнительной абстракции и сложности. Нам нужно определить классы запросов/ответов и их обработчики, написать код для отправки запросов и т.д. Это может быть излишним для простых приложений.
Вопрос не в том, является ли этот компромисс универсально хорошим или универсально плохим, а в том, подходит ли это для вашего конкретного контекста.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/stop-conflating-cqrs-and-mediatr
>>Click here to continue<<