OrderHandler с методом GetNewOrderAsync() ?
А тут кто как уже делает. Сервисы это простой и понятный способ. К тому же их можно комбинировать друг с другом. Ну то бишь типичный юзкейс - анемичные доменные модели, тонкие контроллеры и толстенный слой сервисов. Те, кто достиг дзена, что репозитории - мусор, если речь идёт о EF - просто используют контексты внутри сервисов и особо не переживают. Типичная трёхзвенка с тонкими контроллерами, толстыми бизнесовыми сервисами и тонкой анемичной моделью, представляющей из себя 1-n контекстов и dto'шки с наборами get'теров и set'теров.
Чтобы Handler'ы готовить - это уже ближе к CQRS, но сам по себе он особо проку не принесёт. Его обычно вместе с DDD желательно - тогда от него будет польза. Потому что кода писать больше, чем в случае с сервисами. Потому что сервисы, внезапно, никуда не деваются) Просто они перестают делать бизнесовые вещи, ну то бишь в сервисном слое остаётся, как правило - сугубо инфраструктурная хрень, а-ля "отправить e-mail" или что то вроде того. А переиспользование бизнесовых правил сводится к набору спецификаций в виде Expression<Func<T, bool>>. Ну то бишь тут приходится жертвовать унификацией в обмен на гибкость. Потому что в рамках выполнения отдельно взятой команды, я, например, могу вытащить конекшон из контекса и сделать прямой SQL-запрос, чтобы было быстрее. Ну или что-то навроде того. Отдельная команда/запрос уже покрывает как правило какой-то конкретный юз-кейс. Ну то биль если у тебя минимум логики и тупо CRUD - это будет лютейшим оверкилом. А если логики столько, что жопой ешь, то оно помогает бороться со сложностью, но как я уже подметил - ценой большего количества кода.
Обсуждают сегодня