Нет «приятного» способа доступа к реализациям валидатора для ограничений (электронная почта, не ноль и т. Д.).Хотя вы можете создавать экземпляры этих валидаторов и сохранять их в своем BookInfoValidator
, вам потребуется проделать большую дополнительную работу.Что касается каждого валидатора, его метод ConstraintValidator#initialize()
.Хотя в случае простых ограничений, таких как @NotNull
, на самом деле нет необходимости инициализировать, такую же проверку можно легко выполнить без этого валидатора.А в случае более сложных, таких как @Email
, вам потребуется создать собственный прокси-класс для аннотации, чтобы можно было правильно инициализировать валидатор ограничения.
С учетом сказанного я бы предложил написать класс обертки для вашего Map
, что-то вроде:
public class BookInfoWrapper {
private final Map<String, Object> data;
public BookInfoWrapper(Map<String, Object> data) {
this.data = data;
}
@NotNull
public Map<String, Object> getUser(){
return (Map<String, Object>) data.get( "user" );
}
@Email
public String getEmail(){
return Objects.toString(( getUser() ).get( "email" ));
}
// and any other constraints you need
}
, а затем преобразовать список карт в эти обертки перед проверкой.
Я также вижу, что у вас есть хранилище в вашем валидаторе, поэтому я думаю, что вы, возможно, захотите вывести правила «динамически».В таком случае вы можете попробовать программный API , предоставляемый Hibernate Validator.Используя его, вы сможете создавать необходимые правила на основе данных, извлеченных из базы данных.Но все же сначала вам нужно будет обернуть карты.
Подводя итог, к сожалению, пока нет хорошего и простого решения для вашего конкретного случая.Мы работаем над проверкой объектов свободной формы, но нам потребуется некоторое время, чтобы ее можно было опубликовать.Поэтому я бы посоветовал вам либо
- написать проверочные проверки самостоятельно в своем
BookInfoValidator
без использования встроенных ограничений. - используйте подход обертки, описанный выше.