Как использовать JSR 303 (проверка бина)?

Я прочитал много руководств по спецификации JSR 303, но не вижу ни одного примера, готового к производству. Везде описано как получить Set<Constraintviolation<T>> объект.

Пример:

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
Set<ConstraintViolation<Car>> violations = validator.validate(car);

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

Что мне делать с Set<ConstraintViolation<Car>>? Мне нужно вручную перебрать Set<ConstraintViolation>, собрать все сообщения об ошибках в одну строку, а затем создать исключение с этими сообщениями?

Или существуют какие-то более удобные способы из коробки?

Или лучше предоставить метод validate внутри каждого компонента?


java bean-validation hibernate-validator
person MyTitle    schedule 28.01.2013    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я бы согласился с вашим первым предложением - перебрать нарушения ограничений. Вам не обязательно создавать сообщение об ошибке, содержащее все это. Вероятно, было бы неплохо просто иметь сообщение об ошибке, говорящее bean <bean> is not valid, и установить нарушения ограничений как свойство исключения.

Возможно, вам нужно преобразовать нарушения ограничений в другой объект, потому что в противном случае вы сделаете большую часть своего приложения зависимым от API проверки бина. Возможно, это слишком сильная связь.

Ваша проблема в том, что это очень зависит от конкретного случая, что делать с нарушениями ограничений. Есть много случаев, когда вы хотите информировать не вызывающую сторону о нарушениях ограничения, а какой-то другой объект. Например, в веб-форме вы хотите сообщить своей модели представления, что она также должна отображать эти нарушения ограничений. Генерация исключения — это совсем другое. Обратите внимание, что в большинстве случаев это будет не ConstraintViolationException, а исключение для конкретного приложения.

person SpaceTrucker    schedule 28.01.2013
comment
Note that this won't be a ConstraintViolationException in most cases, but a application specific exception — хорошо, но это исключение для конкретного приложения, скорее всего, будет особым исключением, например BeanValidationException, а не исключением для всего приложения, например ServiceException? т.е. лучше создать другое пользовательское исключение (например, BeanValidationException) вместо повторного использования существующего исключения для конкретного приложения? Спасибо - person MyTitle; 06.02.2013
comment
@MyTitle Да, на мой взгляд, лучше создать исключение, не зависящее от API проверки бина. - person SpaceTrucker; 06.02.2013
comment
хорошо спасибо. Но что вы думаете о том, чтобы выбрасывать такое исключение из сервисного уровня? Хорошо или плохо разрешить моим EJB-методам сигнатуру вроде throws BeanValidationException. Или лучше обернуть его в исключение, специфичное для сервисного уровня (но если я их деформирую, то не смогу реализовать то, что вы упомянули: and set the constraint violations as a property on an exception, потому что мое исключение сервисного уровня не имеет такого свойства)? - person MyTitle; 06.02.2013
comment
@MyTitle Это идет к обсуждению. Попробуйте поискать ответ. Если вы ничего не найдете, вы можете задать более конкретный вопрос. Возможно, этот вопрос поможет вам: stackoverflow.com/questions/ 14722579/ - person SpaceTrucker; 06.02.2013
comment
@MyTitle Только что увидел, что это ты задал этот вопрос. Поэтому вы должны придерживаться принятого ответа. - person SpaceTrucker; 06.02.2013

arrow_upward
1
arrow_downward

Это также зависит от того, как вы используете Bean Validation. Вариант использования, который вы описываете, - это когда вы сами используете Bean Validation API. В этом случае вы получите Set> в результате вызова проверки. Как вы с этим справитесь, зависит от вас. Однако многие технологии интегрируют Bean Validation и часто скрывают все прямые вызовы Bean Validation API. Например ЯПА. Если вы используете JPA и Bean Validation находится в пути к классам, объекты будут автоматически проверяться в событиях жизненного цикла (pre-persist/update/delete), и в случае возникновения javax.validation.ConstraintViolationException ошибки проверки. Как и в JSF, проверка элемента формы с помощью Bean Validation происходит автоматически, и ошибка также может быть выделена. Поэтому, если вы не хотите использовать простой Bean Validation API, вам нужно будет найти примеры того, как выбранная вами технология интегрируется с JSR 303.

person Hardy    schedule 29.01.2013