Валидация бинов в Spring Boot

[@alexandr6055]

О, ничесе канал ожил? С возвращением!)

[@kotbajan]

Я правильно услышал, что вы называете класс CreateUserRequest бином? Если бы это было так, внутри него можно было бы добавить поле с @Autowired и заинжектить туда что-нибудь, либо заинжектить сам бин CreateUserRequest в поле другого бина. В фабрике бинов спринга его тоже нет.

[@Sst886]

Спасибо за видео! У меня остались вопросы, скажите, плз, где лучше применять валидацию на уровне Сервисов или Контроллеров? ДТО или entity? Есть ли тут какие-то "лучшие практики"?

[@AlexSmile-y2x]

1) существует два типа валидации: request validation (валидация набора полей запроса, т.е. проверка наличия, соответствие типов, соответствие форматов) & business validation (валидация полей запроса, т.е. проверка согласования состояния бизнес-сущностей в соответствии с бизнес-требованиями) 2) request validation осуществляется обычно на уровне контроллера способом, который показал автор видео, и валидируется всегда immutable DTO/request, приходящий на вход 3) business validation осуществляется на уровне сервисов, т.к. для проверки согласования бизнес-модели необходимо обращение к модели (например проверка уникальности свойства в системе или наличия определенного состояния сущностей), которое сопряжено с вызовами в кэш, БД и сторонние сервисы. Что описывается на сервисном слое, где удобно поддерживать транзакционность 4) все исключения провала обоих типов валидаций (если не request validation, то обычно это кастомные исключения) бросаются обработчикам, которые показал автор, только exception handlers имплементируются не в контроллере а в ControllerAdvice глобальных обработчиках либо с помощью сторонних либ (например error-handling-spring-boot-starter) 5) также существует подход rich model в DDD, согласно которому модель должна быть богатой, т.е. вся валидация системы (оба типа валидации) описываются непосредственно в сеттерах entity, куда на вход подаются все данные необходимые для этого. Такой подход максимально каноничен и согласован, т.к. невозможно создать неконсистентную либо невалидную сущность, но в то же время это налагает множество ограничений (обязывает осуществлять валидацию там, где это не привычно и кажется не нужным на первый взгляд), например при описании тестов неуспешных кейсов, или при использовании библиотек, которые используют дефолтные сеттеры для создания сущностей (как Hibernate) etc.

[@devmark]

@@AlexSmile-y2x Спасибо за столь подробное уточнение, даже добавить нечего)

[@Sst886]

@AlexSmile-y2x Спасибо! скажите, плз, правильно ли я понял, что @Valid запускает проверку для обоих уровней: 1) аннотаций пакета jakarta.validation.constraints для request validation, если я укажу @Valid в контроллере и 2) аннотаций пакета jakarta.persistence для business validation, если я укажу @Valid в сервисах?

[@AlexSmile-y2x]

@ спасибо тебе за музычку на фоне (обожаю джаз и релакс-музыку ;)

[@dmitrelkin9256]

Спасибо за вашу работу! А можно ссылку на обработку ошибок? или это имелось в виду видео "GraphQL в Spring Boot: обработка ошибок"?

[@devmark]

Нет, я имел в виду обработку ошибок именно для REST. Вот тут можно посмотреть kzbin.info/www/bejne/rmbNk6Oeq9qUjJosi=O0GAPecJmCWJSqQG

[@АлексейКудрявцев-й8з]

Спасибо большое. А как сделать комбинированный валидацию из двух полей?

[@devmark]

Это уже надо кастомный валидатор писать, декларативно не получится.