Проверка Spring против проверки Hibernate с использованием аннотации - PullRequest
Новая
       9

Проверка Spring против проверки Hibernate с использованием аннотации

9 голосов
/ 22 декабря 2011

Я создаю демонстрационное приложение с использованием Spring mvc 3.0. Я должен применить проверку по экрану. Я выполняю поиск в сети и обнаружил, что в приложении используется в основном 2 типа проверки:

  1. Весенние проверки с использованием проверок Api
  2. Проверка гибернации с использованием проверок гибернации

Надеюсь, кто-нибудь подскажет, какой из них лучше всего реализовать в приложении.

1 Ответ

9 голосов
/ 22 декабря 2011

Я использовал оба - мне больше нравится Hibernate Validation - довольно легко реализовать и довольно стандартно.Он автоматически включается, когда у вас есть реализация на пути к классам.Вот пример: 

@EmailValidator
@NotBlank
@Length(max=65)
private String email;

Откуда исходит сообщение Error String?В WEB-INF у вас должен быть файл messages.properties: 

NotBlank.ForgotPasswordBackingObject.email=Email address must be present

Существует стандартная аннотация @Email, но электронная почта, такая как: me @ mycompany, считается действительной, поэтому мне пришлосьсделать свой собственный @EmailValidator (в стандартной реализации изменил флаг регулярного выражения с * на +).Я столкнулся с некоторыми проблемами: порядок проверки - какую проверку вы хотите выполнить в первую очередь, это делается с группами проверки, но это невозможно с аннотацией @Valid, например: 

@RequestMapping(method=RequestMethod.POST, value="/auth/changePassword")
public ModelAndView submitChangePasswordPage(@Valid @ModelAttribute("ChangePasswordBackingObject") ChangePasswordBackingObject backingObject, BindingResult result, Principal principal)

Вот почему, если у вас есть ваш контроллер в этой форме (например, в Spring MVC), то вы должны смоделировать свою логику таким образом - я тоже это сделал.может сделать это для проверки двух или более полей одновременно (что я нашел довольно полезным): 

@FieldMatch.List({
    @FieldMatch(firstValue = "password" , secondValue = "confirmPassword")
})
public class RequestAccountBackingObject implements Serializable {
    private String password;
    private String confirmPassword;

И реализация: 

@Target({TYPE, ANNOTATION_TYPE})
@Retention(RUNTIME)
@Constraint(validatedBy = FieldMatchImpl.class)
@Documented
public @interface FieldMatch{
    String message() default "{com.errorMessage}";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
    String firstValue();
    String secondValue();
    @Target({TYPE, ANNOTATION_TYPE})
    @Retention(RUNTIME)
    @Documented
    @interface List
    { FieldMatch[] value(); }
}

Другой FieldMatchImpl будет: 

public class FieldMatchImpl implements ConstraintValidator<FieldMatch, Object>{
    private String firstFieldName;
    private String secondFieldName;

и вам нужно реализовать два метода: 

public void initialize(final FieldMatch constraintAnnotation){
    firstFieldName = constraintAnnotation.firstValue();
    secondFieldName = constraintAnnotation.secondValue();

Также: 

public boolean isValid(final Object value, final ConstraintValidatorContext context){

    final String firstObj = BeanUtils.getProperty(value, firstFieldName);
    final String secondObj = BeanUtils.getProperty(value, secondFieldName);

Используя org.apache.commons.beanutils.BeanUtils, вы теперь можете проверить дваполя.

Примерно так: 

boolean result = firstObj.equals(secondObj);
if(!result) {
    context.disableDefaultConstraintViolation();
    context.buildConstraintViolationWithTemplate(errorMessage).addNode(firstFieldName).addConstraintViolation();
}

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

...