Сугубо мое скромное мнение, в этой архитектуре CQRS применяется только ко внешним запросам, т.е. мы проектируем WEB API с оглядкой на CQRS. При этом медиатор служит не для CQRS запросов внутри приложения, а для вынесения логики в application слой, где уже в обработчиках запросов медиатора вы можете подтягивать через DI нужные сервисы, репозитории и т.д., выносить повторяющуюся логику в свои сервисы и вызвать их в нужных обработчиках.
Пусть автор поправит меня, если я не правильно понял.
В чем вы видите сложность? Реализуете всю необходимую логику в обработчике медиатора. Через DI подтягиваете в него нужные сервисы, будь то репозитории, шины или внешние сервисы.
Мне кажется сейчас основная проблема WASM это необходимость тянуть рантайм в браузер, точнее его вес, что делает загрузку страницы слишком долгой для продакшена. Плюс необкатанность технологии, которая ставит крест на выборе в пользу WASM на серьезном проекте.
А вот для создания админок технология выглядит очень даже интересно.
Паразитные мысли часто заставляют ваши конечности совершать непроизвольные движения? Мне кажется управление компьютером "силой мысли" надо сравнивать со слепым набором на клавиатуре.
Согласен, использовать docker для ci удобно. Но бывает так как у меня: пул приложений Net Core, но одно из них Desktop Net Framework 4.8 и это перечёркивает возможность унифицированного использования docker для ci.
можно ещё бани сделать для сисадминов
Для запросов в БД можно сделать репозиторий и переиспользовать его в обработчиках.
Сугубо мое скромное мнение, в этой архитектуре CQRS применяется только ко внешним запросам, т.е. мы проектируем WEB API с оглядкой на CQRS. При этом медиатор служит не для CQRS запросов внутри приложения, а для вынесения логики в application слой, где уже в обработчиках запросов медиатора вы можете подтягивать через DI нужные сервисы, репозитории и т.д., выносить повторяющуюся логику в свои сервисы и вызвать их в нужных обработчиках.
Пусть автор поправит меня, если я не правильно понял.
Медиатор в такой архитектуре служит для вынесения бизнес логики в application слой. А контроллеры реализуют исключительно presentation слой.
В чем вы видите сложность? Реализуете всю необходимую логику в обработчике медиатора. Через DI подтягиваете в него нужные сервисы, будь то репозитории, шины или внешние сервисы.
Чтобы роботы полностью заменили программистов, клиентам нужно научиться четко и понятно формулировать задачи. Мы в безопасности.
Я это к тому, что может это вас так кто-то держит в тонусе?)
Время от времени заходите на сайт вашего конкурента, используя Internet Explorer 6. Держите их в тонусе!
Мне кажется сейчас основная проблема WASM это необходимость тянуть рантайм в браузер, точнее его вес, что делает загрузку страницы слишком долгой для продакшена. Плюс необкатанность технологии, которая ставит крест на выборе в пользу WASM на серьезном проекте.
А вот для создания админок технология выглядит очень даже интересно.
Точно так же, как вы фильтруете свои, чтобы набирать правильную последовательность символов на клавиатуре.
Паразитные мысли часто заставляют ваши конечности совершать непроизвольные движения? Мне кажется управление компьютером "силой мысли" надо сравнивать со слепым набором на клавиатуре.
Согласен, использовать docker для ci удобно. Но бывает так как у меня: пул приложений Net Core, но одно из них Desktop Net Framework 4.8 и это перечёркивает возможность унифицированного использования docker для ci.