Хм. А как тогда юзер узнает, что он в данных регистрации на фронте нашкодил ??

Валидация эмайла по его уникальности по идее происходит исключительно на сервере

Если валидатор зафейлит, есть такой обьект Errors, его вместе с дто указываешь в мэсигнатуре метода контроллера. А внутри проверяешь примерно так:
if (errors.hasErrors()) return "..."
А в форме указываешь тег ошибки, и если они есть, то будет выводится сообщение об этом, на фронте.

Я как раз сегодня такое делал. Минут за 10 смогу подробно все разжевать.

Окей, уже могу.
Значит так, у тебя есть метод для регистрации в контроллере, примерно такой:

@PostMapping("/registration")
public String processRegistration(@Valid @ModelAttribute("user") UserDTO userDto, Errors errors) { }

Внутри метода делаешь проверку, у меня она такая:

if (errors.hasErrors()) {
    return "registration";
}

UserDTO - это POJO пользователя, у него есть поля по типу пароля и емейла.
Аннотация Valid означает, что все валидаторы прошли по обьекту успешно. Внутри обьекта пользователя у меня есть поле:

@UniqueEmail(message = "There is already user with such email! Please, choose another one.")
private String email;

Аннотация запускает валидатор, тот, с помощью сервиса, обращается в базу данных и проверяет, нет ли там уже такого адреса, вот метод валидатора:

public boolean isValid(String email, ConstraintValidatorContext constraintValidatorContext) {
    return email != null && userService.getByEmail(email) == null;
}

С беком вроде всё. Алгоритм такой:
В метод processRegistration приходит класс пользователя, проверяется на валидность с помощью валидаторов и если есть проблемы, то возвращается форма. А в форме вот такие теги:
<small><form:errors path="password" class="errors"/></small>
И всё.

> Аннотация Valid означает, что все валидаторы прошли по обьекту успешно.
Вот тут не совсем верно. Аннотация означает, что обьект должен валидироваться.

ааа. Я так понял из вашей логики не нужно юзать вообще задавать код ошибки в теле запроса и пробрасывать код ошибки дальше в обработчик эксепшенов эндпоинта ( например, в ExceptionHandler ) и тем более устанавливать в нём статус код ???

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

Ок. Я конечно верю вам уже больше 60% как минимум, но пока не на все 100% Так как я не знаю как валидатор тут поможет ибо он вынужден обращаться к БД, чтобы проверить уникальносмть e-maila. В кастомный валидатор заинджектить сервис и.т.д. Я никогда не видел в гайдах спринга как например в baeldung.com, чтобы валидатор юзал БД, чтобы проверить уникальность записи.

Ну, для проверки уникальности в любом случае нужно обращение к базе. А поскольку такая проверка на уникальность, это, по сути, валидация, то и производиться она должна в валидаторе.

хорошо сделаем так с валидатором. Надеюсь получится. Спасибо, что вселили уверенность в том, что делать. 😊

Вот еще гайд.
https://medium.com/@wkrzywiec/how-to-check-if-user-exist-in-database-using-hibernate-validator-eab110429a6

спасибо почитаю :)

профессиональная Java для веб-приложений, написанная Николасом С. Уильямсом

есть где-то файликом эта книга?)

в инете определенно есть

Возник такой вопрос: Какие обьекты должны быть в приложении? Имею в виду, где должны быть DTO, где BO, а где DAO. Я просто никогда реальных приложений не видел, поэтому не знаю, как лучше строить архитектуру. Сейчас прикинул себе такой вариант, но не знаю, правильно ли это:
Для работы с фронтэндом я использую DTO-классы, у них есть только те поля, которые можно ввести с формы на фронте. Для каждом формы на фронте создается свой DTO-класс. Пример: RegistrationForm(для формы регистрации пользователя), EditProfileForm(для формы редактирования профиля пользователя). В таких классах нет никакой логики, исключительно поля для транспортировки между фронтэндом и бекэндом.
Для работы с базой использую DAO-классы, в них есть только те поля, которые требуют персистентности, то есть, практически все поля, которые могут быть у теоретического пользователя. Эти классы помечены аннотацией Entity и их структура максимально простая, никакой логики, только поля. Так же, эти классы я пытаюсь держать максимально близко к той части приложения, где производится работа с базой, а в бизнес логику я их не пускаю.
Для бизнес логики я использую обычные классы, которые имеют все нужные пользователю поля и могут содержать какое-то поведение.
Проблемы, которые я заметил:
Например, для условного класса пользователя, все 3 класса(DTO, BO и DAO) почти одинаковые, то есть содержат одни и те же поля, за исключением пары полей. В результате, код дублируется и в случае изменения одного из этих трех, придется менять как минимум еще один. Пример: Изменилась форма на фронте и теперь DTO принимает еще одно поле, значит такое же поле нужно добавить и в BO, а если его еще и нужно сохранять в базу, то и DAO придется менять.
Прошу подсказать, как такие вещи решаются в реальных приложениях, какие для этого существуют паттерны и где об этом можно почитать. Если же описанная выше схема приемлема, то прошу указать на минусы или идеи для улучшения.

ВО - это что?

БизнесОбъект? )

в общем все верно написано, только изменение формы на фронте это скорее следствие того что вы меняете бизнеслогику, а не наоборот.

Да.