На одном из проектов, использовали чуть другую схему. Репозитории объединялись в unit of work, при этом в хэндлерах команд и кверей происходил вызов не сервисов, а обобщенных интерфейсов с прокидыванием необходимой сущности в обобщение, данные которой необходимо использовать, например: ICommandRepository на создание/изменения, IQueryRepository на чтение из репозитория Users. Не помню правда как назывался этот паттерн, но был один из самых удобных
@@Excalib ну у нас эвенты тоже были, но были завязаны не на бд, а на сервисы. Но в целом да, играть можно с cqrs как угодно, строгих паттернов нет смысла придерживаться, их нужно адаптировать под каждый конкретный проект, лишь бы было удобно и практично)
Хорошее видео, но мне кажется стоит прекращать смешивать cqrs и mediatr. Во первых они не шибко связаны и получается две не самые простые темы за раз. Во вторых тут есть разные альтернативы и mediatr не лучший выбор среди них. В общем я в некотором смысле хейтер mediatr-а и в проектах проще работать с этими самыми командами и кверями как есть (как на схеме про CQRS нарисовано)
Вопрос хороший и я им тоже задавался в свое время, мнения расходятся, но я считаю, что допустимо использовать команды, но если хочешь структурировать подход, то добавляй реквесты, поэтому делай как удобнее, проблемы с этим не будут)
здаров можешь помочь как опубликовать приложение Blazor Webassebly, пробую способ как твой но при попытке запустить дебаг или релиз dll вылезает ошибка
@@Excalib я смотрел его, очень помогло и статья, которую дали. Очень интересная, спасибо. Команда реализующая IRequest и обработчик реализующий IRequestHandler. Эти два файла в одной папке но в разных файлах. Слоя application.
@user-qu6ni1gl4u смотрите на это с точки зрения появления проблем, основным критерием правильного распределения классов будет являться то, что в будущем у вас не возникнет проблем с ссылками на проекты, на текущем этапе старайтесь писать больше кода и меньше обращать внимание на такие тонкости, с практическим опытом придет и наточенный до автомата навык распределения классов по слоям
Достаточно просто и понятно про CQRS, маловато про смысл медиатора) Но норм, посмотрел, сейчас буду пробовать)
Мне буквально вчера дали таску переделать обычные сервисы в CQRS, как же вовремя)
На одном из проектов, использовали чуть другую схему.
Репозитории объединялись в unit of work, при этом в хэндлерах команд и кверей происходил вызов не сервисов, а обобщенных интерфейсов с прокидыванием необходимой сущности в обобщение, данные которой необходимо использовать, например: ICommandRepository на создание/изменения, IQueryRepository на чтение из репозитория Users. Не помню правда как назывался этот паттерн, но был один из самых удобных
думаю что это часть CQRS+Event Sourcing, в моём проекте нет UoW, но в целом при желании почему бы и нет:)
@@Excalib ну у нас эвенты тоже были, но были завязаны не на бд, а на сервисы. Но в целом да, играть можно с cqrs как угодно, строгих паттернов нет смысла придерживаться, их нужно адаптировать под каждый конкретный проект, лишь бы было удобно и практично)
Repo в uow😂😂😂
Спасибо большое!
Хорошее видео, но мне кажется стоит прекращать смешивать cqrs и mediatr. Во первых они не шибко связаны и получается две не самые простые темы за раз. Во вторых тут есть разные альтернативы и mediatr не лучший выбор среди них. В общем я в некотором смысле хейтер mediatr-а и в проектах проще работать с этими самыми командами и кверями как есть (как на схеме про CQRS нарисовано)
на схеме нарисован CQRS+ES)
не понимаю вообще зачем медиатор,
чтобы вызвать метод какого-то сервиса
использовать для этого медиатр?
видится как не нужная прокладка
Привет. А стоит ли принимать команды прям в контроллер или создать дто/реквесты и потом мапить их в команды?
Вопрос хороший и я им тоже задавался в свое время, мнения расходятся, но я считаю, что допустимо использовать команды, но если хочешь структурировать подход, то добавляй реквесты, поэтому делай как удобнее, проблемы с этим не будут)
здаров можешь помочь как опубликовать приложение Blazor Webassebly, пробую способ как твой но при попытке запустить дебаг или релиз dll вылезает ошибка
Привет! А зачем обработчик определили в слое infrastructure? У меня например все в Аpplication. Считается ли это ошибкой ?
Какой обработчик? Ошибкой не считается важен контекст использования, кстати про ваш вопрос я подробно объясняю в видео про Чистую архитектуру
@@Excalib я смотрел его, очень помогло и статья, которую дали. Очень интересная, спасибо. Команда реализующая IRequest и обработчик реализующий IRequestHandler. Эти два файла в одной папке но в разных файлах. Слоя application.
@@Excalib ну в нем я вызываю repository, значит нужно определить в infrastructure получается?
@user-qu6ni1gl4u смотрите на это с точки зрения появления проблем, основным критерием правильного распределения классов будет являться то, что в будущем у вас не возникнет проблем с ссылками на проекты, на текущем этапе старайтесь писать больше кода и меньше обращать внимание на такие тонкости, с практическим опытом придет и наточенный до автомата навык распределения классов по слоям
@@Excalib спасибо