Создание правил сущностей

Question

Я хотел бы знать ответ на этот простой вопрос.

Когда я создаю объект сущности и хочу ограничить настройку атрибута (например, я не хочу позволять кому-либоустановить целочисленное значение для атрибута меньше 1), должен ли я реализовать его в установщике этого атрибута или я должен проверить это последнее ограничение в классе, который обрабатывает эти объекты?В общем, могу ли я реализовать методы получения и установки, однако я хочу, чтобы мои методы получения и возврата устанавливали атрибуты?

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

Заранее спасибо, надеюсь, что мой вопрос достаточно ясен и прошу прощения за любые грамматические ошибки, которые я мог сделать: /.

Answer 1

Да, для этого полезны геттеры / сеттеры.

например:

public void setAge(int age){
 if(age < 0){
  throw new IllegalArgumentException("Invalid age : " + age);
  //or if you don't want to throw an exception you can handle it otherways too
 }
}

Для этого

вы также можете использовать Bean Validators Java-EE

public class Person{

   @Min(value = 0)
   @Max(value = 99)
   private Integer age;

   //some other code
}

Answer 2

Мой предпочтительный подход заключается в использовании JSR 303 (API проверки бинов), чтобы убедиться, что свойства класса действительны.

Это вполне нормально для проверки в установщиках, но это не всегда желательный подход. Существует возможность смешивания потребностей нескольких контекстов, которые не связаны друг с другом. Например, некоторые из ваших свойств никогда не должны устанавливаться из пользовательского интерфейса, а вместо этого будут вычисляться службой, прежде чем будут сохранены. В таком случае нежелательно иметь эту логику внутри установщика, поскольку вам необходимо знать контекст, в котором вызывается установщик; вам нужно будет применять разные правила на уровне пользовательского интерфейса и на уровне постоянства. JSR 303 позволяет вам разделить эти проблемы с помощью групп проверки, чтобы ваша группа проверки пользовательского интерфейса отличалась от вашей группы проверки постоянства.

В JPA 2.0, когда вы аннотируете свой класс с помощью ограничений, которые оцениваются валидатором JSR 303, ваш поставщик сохраняемости может автоматически оценивать эти ограничения на PrePersist, PreUpdate и PreRemove (обычно это не делается; см. ниже) события жизненного цикла объектов. Чтобы выполнить проверку сущностей в вашем JPA-провайдере, вы должны указать либо элемент validation-mode, либо свойство javax.persistence.validation.mode в вашем файле persistence.xml; значения должны быть либо AUTO (по умолчанию), либо CALLBACK (а не NONE).

Наличие поставщика Bean Validation является достаточным для того, чтобы гарантировать, что проверка происходит в событиях жизненного цикла сущности JPA, поскольку значением по умолчанию является AUTO. Вы получаете это по умолчанию на сервере приложений Java EE 6; Glassfish использует RI-реализацию JSR 303, которая является Hibernate Validator, и она также хорошо работает с EclipseLink.

Режим CALLBACK позволит вам переопределить группы проверки, которые должны применяться при запуске событий жизненного цикла. По умолчанию группа проверки Bean по умолчанию (Default) будет проверяться на наличие обновлений и постоянных событий; Событие удаления не требует проверки. Режим CALLBACK позволяет вам указать другую группу проверки для этих событий, используя свойства javax.persistence.validation.group.pre-persist, javax.persistence.validation.group.pre-update и javax.persistence.validation.group.pre-remove.

Имейте в виду, что проверку JSR 303 можно использовать вне контейнера Java EE, хотя ссылка на документацию по API Bean Validation, которую я разместил выше, взята из документации по API Java EE 6.

Answer 3

Это цель добытчиков и сеттеров.

Если мы не можем добавить какое-либо поведение в эти методы, ну ... почему бы нам не использовать публичные атрибуты?

Answer 4

Геттеры и сеттеры отлично подходят для добавления ограничений, как и Джигар Джоши в своем ответе.Таким образом, вы сразу получаете обратную связь и можете решить проблему, когда она будет введена.

Другое решение - использовать проверку объекта (что-то вроде реализации JSR-303), которая позволит вам аннотировать поле с помощью min.и максимальные значения.Что-то вроде

@Min(value=1)
private int myvalue;

Тогда вы можете проверить весь объект за один раз и получить все сообщения, если у вас есть другие ограниченные поля.Это, очевидно, бесполезно везде, но если это соответствует вашим потребностям, это опция.

Наконец, когда вы говорите «сущность», я думаю о чем-то, что хранится в базе данных или связано с инструментами ORM.Если это так, вы должны быть осторожны с тем, что вы делаете в своем геттере.Например, если вы выполняете ленивую инициализацию в получателе, некоторые поставщики ORM пометят сущность как грязную и попытаются сбросить ее в базу данных, что может вызвать непреднамеренную запись.

Answer 5

Из моего понимания вашего вопроса, это в значительной степени связано с принципом инкапсуляции ОО. Вы можете посмотреть на эту статью: http://www.tutorialspoint.com/java/java_encapsulation.htm