2013-07-07 1 views
2

Я читал много о API проверки боба, который сопровождает Java EE 6+, и я понимаю основы того, как работает api validation api, но в документации, которую я читал, все примеры - это единичные тесты, которые не помогают мне понять WHERE, чтобы реализовать операции проверки.Проверка фасоли с EJB

Я разрабатываю систему трехуровневой архитектуры. Я хотел бы разместить проверку на уровне сервиса, поэтому я могу повторно использовать код проверки, если уровень представления отличается (например, Jax-RS, JSF и т. Д.). Но я смущен тем, как реализовать указанные операции. Вот где я застрял:

У меня есть beans, которые взаимодействуют с различными сущностями в моей модели. Например, это метод в моем компоненте для взаимодействия с пользователем ->

public User getUser(
      @Min(value = 0, message = "Must have a positive userId") int uid) 
      throws RetrievalNotFoundException { 

     try { 

      // I WANT TO VALIDATE UID HERE 

      // find User with provided uid 
      User foundUser = em.find(User.class, uid); 

      // IF the user is inactive 
      if (foundUser.getIsActive() == 0) { 
       // cannot find the content 
       throw new RetrievalNotFoundException(); 
      } 

      // close the entity manager 
      em.close(); 
      // return the user 
      return foundUser; 


    } 

Вот пример из документации спящем:

Car object = new Car("Morris"); 
Method method = Car.class.getMethod("drive", int.class); 
Object[] parameterValues = { 80 }; 
Set<ConstraintViolation<Car>> violations = executableValidator.validateParameters(
     object, 
     method, 
     parameterValues 
); 

assertEquals(1, violations.size()); 
Class<? extends Annotation> constraintType = violations.iterator() 
     .next() 
     .getConstraintDescriptor() 
     .getAnnotation() 
     .annotationType(); 
assertEquals(Max.class, constraintType); 

Действительно ли я должен instatiate боб снова открыть его метод GetUser()? Я запутался. Другой вопрос, который у меня был, это то, что произойдет, если кто-то решит включить int для uid, который переполняет контейнер int? Как я могу это подтвердить?

Большое спасибо за вашу помощь, Я очень ценю это.

ответ

4

Несколько комментариев к вашему вопросу. Во-первых, проверка Bean действительно является частью EE 6 и EE 7. Однако EE 6 включает только Bean Validation 1.0, тогда как EE 7 включает в себя проверку бинов 1.1. Разница в том, что Bean Validation 1.0 еще не включает проверку методов, и это то, что вы показываете в своих примерах. Hibernate Validator содержит начиная с версии 4 API проверки подлинности метода Hibernate Validator, но это не является частью стандарта и немного отличается от того, что указано в Bean Validation 1.1 и Hibernate Validator 5.

Второй комментарий касается кода, необходимого для выполнения проверки метода. Проверка боба только обеспечивает механизм для проверки уровня метода. Это API, на который вы ссылаетесь в своем примере. В большинстве случаев вам нужна какая-то технология перехвата, чтобы использовать ее. Java EE 7, например, выполняет проверку метода по умолчанию с использованием перехватчиков CDI. Это часть стандарта. См. http://beanvalidation.org/1.1/spec/#integration-cdi. Если вы хотите использовать EE 6, вам нужно будет написать свою собственную логику перехвата, используя технологию по вашему выбору.

Относительно последнего вопроса. Я не думаю, что переполнение обнаруживается вообще. В этом случае ничего не может сделать проверка бина.

+0

Спасибо, много полезной информации. На самом деле я использую Java EE 7 со средой времени работы Glassfish 4.0. Я думаю, что тогда проверка уровня метода выполняется по умолчанию, как вы сказали. Я думаю, что я должен написать свои собственные валидаторы, а затем для методов с более длинными списками параметров, чтобы не вставлять все ограничения на параметры. Спасибо за помощь! –

+1

Правильно, EE7 с Glassfish 4 имеет проверку метода в соответствии со спецификацией, на которую я ссылался. Что касается пользовательских ограничений, вы можете точно создать свои собственные, но я не вижу, как это уменьшает количество аннотаций. Если, конечно, вы не хотите объединить несколько ограничений в одно ограничение на компоновку. Это, конечно, уменьшило бы количество аннотаций на места по параметрам. – Hardy