Должна ли валидация в CQRS происходить отдельно, один раз в пользовательском интерфейсе и один раз в бизнес-сфере?
Простой запрос для списка первой рекурсии:
select @pv:=id as id, name, parent_id
from products
join (select @pv:=19)tmp
where parent_id=@pv
Результат:
id name parent_id
20 category2 19
21 category3 20
22 category4 21
26 category24 22
... с левым соединением:
select
@pv:=p1.id as id
, p2.name as parent_name
, p1.name name
, p1.parent_id
from products p1
join (select @pv:=19)tmp
left join products p2 on p2.id=p1.parent_id -- optional join to get parent name
where p1.parent_id=@pv
Решение @tincot для перечисления всех дочерних элементов:
select id,
name,
parent_id
from (select * from products
order by parent_id, id) products_sorted,
(select @pv := '19') initialisation
where find_in_set(parent_id, @pv) > 0
and @pv := concat(@pv, ',', id)
Проверьте его онлайн с помощью Sql Fiddle и просмотрите все результаты.
2 ответа
Я думаю, что мой вопрос был только что решен в другой статье, Уточненный CQRS Уди Даханом. Раздел «Команды и проверка» начинается следующим образом:
Команды и проверка
Обдумывая, что может сделать ошибка команды, одна тема, которая появляется, является проверкой. Валидация отличается от бизнес-правил тем, что в ней указывается независимый от контекста факт о команде. Либо команда действительна, либо нет. Бизнес-правила, с другой стороны, зависят от контекста.
[& hellip;] Даже если команда может быть действительной, все же могут быть причины отклонить ее.
Таким образом, проверка может быть выполнена на клиенте, проверяя наличие всех полей, требуемых для этой команды, диапазоны чисел и дат в порядке, и тому подобное. Сервер все равно будет проверять все поступающие команды, не доверяя клиентам выполнять проверку.
Я понимаю, что это означает, что & mdash; учитывая, что у меня есть пользовательский интерфейс на основе задач, как часто предлагается для CQRS, чтобы работать хорошо (команды как глаголы домена) & mdash; Я бы выделил (отключить) кнопки или пункты меню только серым цветом, если команду еще нельзя отослать, потому что некоторые данные, необходимые для команды, все еще отсутствуют или недействительны; то есть. пользовательский интерфейс реагирует на саму достоверность команды, а не на будущее влияние команды на объекты домена.
Таким образом, команды CanDoX не требуются, и в пользовательский интерфейс не требуется пропускать логику проверки домена. Однако пользовательский интерфейс будет иметь некоторую логику для проверки команд.
Проверка на стороне клиента в основном ограничена проверкой формата, потому что сторона клиента не может знать состояние модели данных на сервере. То, что действительно сейчас, может быть недействительным через полсекунды.
Таким образом, клиентская сторона должна проверять только все ли обязательные поля заполнены и имеют ли они правильную форму (поле адреса электронной почты должно содержать действительный адрес электронной почты, например, формы (. +) @ (. +). (. +) или тому подобное).
Все эти проверки, наряду с проверками бизнес-правил, затем выполняются на модели предметной области в службе команд. Таким образом, данные, которые были проверены на клиенте, могут по-прежнему приводить к недействительным командам на сервере. В этом случае некоторые отзывы должны быть в состоянии вернуться к клиентскому приложению ... но это уже другая история.