Comments 11
Поправьте аннотации, у вас невалидный код. Должно быть типа:
@Data
public class UserDTO {
private Long userId;
@NotNull
@Length(min = 2, max = 10)
private String userName;
@NotNull
@Length(min = 6, max = 20)
private String account;
@NotNull
@Length(min = 6, max = 20)
private String password;
}
Статья плохо оформлена в части листинга кода. И как всегда упущен момент с валидацией, когда параметры валидации одного поля (например password) зависят от значения другого поля (например, userName)
Стандарт такого не позволяет - есть только валидатор класса. Но это спорный вопрос, есть по этому куча вопросов, объяснений и жалоб в интернете.
Я видел кучу решений начиная от валидаторов на уровне класса, через @GroupSequenceProvider, кастомные костылей в виде бинес-валидаций. Автор мог бы и разобрать это в статье, потому что все остальное - буквально пересказ документации.
Наверное нужно объяснение в чем проблема:
Обычно для валидации поля валидатор пишется на нем. Но если у вас есть зависимые поля, то по стандарту можно написать только валидатор класса. И тут возникает противоречие - зачем писать валидаторы на полях, если нужно писать еще и валидатор класса - это порезать логику валидации на два куска - и все из-за того что зависимый валидатор на поле написать нельзя.
Моя попытка написания такого валидатора закончилась неудачно. Для такого валидатора нужно получить сам объект. В самом стандарте это сделать нельзя, поэтому нужно опираться на конкретную реализацию - это уже плохо. В реализации гибернейта вроде как можно получить объект, но через такие гланды, и то не всегда: оно выглядит так коряво, что лучше все-таки писать валидатор класса.
Минимальные требования:
Spring 6.0+
SpringBoot 3.0+
А до этого без валидации в спринге жили?)
Блин, это конечно хорошо, но по заголовку я ожидал что, наконец-то, добавили возможность работы с асинхронным кодом/корутинами/webflux. А так получается if/else - наше всё
Всё ещё используете If/else валидацию в Spring 6.0+ / SpringBoot 3.0+?