блогам, но так и не пришел к единому мнению. У меня сложилась следующая картинка в голове. (Возможно ошибочная)
В моем понимании есть три уровня валидации.
- Валидация на уровне Реквеста, ( проверка что пользователь ввел почту, а не какую то херню, что поля заполнены, проверка на уникальность что не может быть двух юзеров с одинаковым емаилом)
Это в моем понимании валидация пользовательская, пользователь не прав мы об этом ему сказали путем например ответа с кодом 422 и месагой что вы ввели неверный эмаил.
- Валидация на уровне сущностей и бизнес логики. Взять того же юзера, то в конструкторе например проверить что email действительно email, а не какая то дичь. Если это дичь то бросить исключение вроде InvalidArgumentException. Если отсюда вылетел экзепшен, мы пишем его в логи. Хендлим этот экзепшен где то на выходе и отрисовываем Пользователю ответ, мол ошибка сервера, попробуйте позже. Верно ли я понимаю что эти экзепшены они для программиста? Пользователю не нужно знать о том что внутри что то пошло не так. Пользователю мы сообщаем на первом уровне.
- Третья валидация это даже не валидация, а защита от дурака на уровне связей в таблицах. Когда уже бд сообщает о том что произошел 'пробой' , на первых двух и мы пытаемся записи в бд привести в несогласованное состояние (например два пользователя в системе с одним email). Верно ли я понимаю, что такое поведение мы тоже хандлим в логи, а пользователю пишем мол ошибка сервера.
Ну и еще. Верно ли я понимаю что если пошел рассинхрон 1го уровня валидации со вторым, то собственно с логов прогеры видят где пошло что не так. И уже потом смотрят что нужно докрутить, пользовательскую валидацию или правила в БЛ. Спасибо
Вообще как таковой первой, третьей, пятой валидации нет, есть проверка - контракта - реквест, cli аргументы, дто - здесь проверка на типы, да мейл может быть отдельным типом, может еще проверка на диапазоны и тп, но с ними спорная тема и зависит от ситуации. Дальше уже проверка инвариантов - в твоем случае - не может быть двух пользователей с одинаковой почтой, или мейл уже заблочен или был уже использован или еще что-то - и это уже уровень бизнес логики и здесь как раз пользователю нужно сообщать что он делает что-то не то. На счет бд, я бы сказал не защита от дурака, а механизм сохранения целостности данных.
на счет исключений в проверке инвариантов и бизнес логике https://reflectoring.io/business-exceptions/
Обсуждают сегодня