Я столкнулся с дизайнерским решением в моем проекте GWT + Hibernate.
Я объясню свой вопрос, используя сущность компании.
@Entity
@Table(name = "Company")
public class Company extends LightEntity implements BaseSerializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "Id")
private int id;
@Column(name = "Code")
private String code;
@Column(name = "Name")
private String name;
@Column(name = "Address")
private String address;
@Column(name = "ContactNumber1")
private String contactNumber1;
@Column(name = "ContactNumber2")
private String contactNumber2;
@Column(name = "EMail")
private String email;
@OneToMany(fetch = FetchType.LAZY, mappedBy = "company", cascade = CascadeType.ALL)
private List<CompanyRegistration> companyRegistrations = new ArrayList<CompanyRegistration>();
public Company() {
}
public Company(String code, String name) {
this.setCode(code);
this.setName(name);
}
// getters & setters
}
Действительный объект Company всегда должен иметь допустимый код и имя. Остальные свойства необязательны. Следовательно, я предоставил конструктор с двумя аргументами, чтобы обеспечить создание действительного объекта.
В настоящее время.
Я привык проверять данные в сеттерах. Я также использую эти сеттеры в своих конструкторах. Это гарантирует, что новый объект всегда имеет допустимое состояние. Это мой план по внедрению объектов Hibernate.
Однако GWT-RPC предписывает использовать конструктор noargs по умолчанию, чтобы его можно было использовать для отложенной привязки. Но это также позволит любому создать пустой объект, что нежелательно в большинстве моих сущностей Hibernate. Например, компания всегда должна создаваться с кодом и названием. Конструктор noargs игнорирует это правило.
Теперь в Hibernate реализован стандарт (JSR-303, если мне не изменяет память) для фреймворка валидации. Он позволяет вам вызывать проверки уже созданного объекта.
Моя проблема возникла из-за конструктора noargs. Если бы это не было обязательным, я бы покончил с проверками в сеттере.
Если я реализую проверки в сеттерах, это означает, что недопустимый объект выйдет из строя как можно быстрее. Мне не нужно будет вызывать проверку объекта на стороне клиента. Но пустой объект (созданный с помощью конструктора noargs) не может быть проверен таким образом. Это может привести к сервису, подразумевая, что я также должен реализовать проверки, многие из которых могут быть такими же, как сеттеры, на уровне сервиса.
Если я реализую структуру проверки, то мне придется вызывать проверку для каждого объекта, который я создаю на стороне клиента. Если я забуду проверить один из них, он может перейти на сервисный уровень в недопустимом состоянии. Однако я могу легко использовать ту же структуру на сервисном уровне.
Одно из решений, о котором я подумал, состоит в том, чтобы в любом случае реализовать проверки в установщиках, но также использовать валидатор на уровне службы перед отправкой объекта для сохранения в базе данных. Таким образом, клиентская сторона будет автоматически ограничена сеттерами. С другой стороны, если пустой объект каким-либо образом отправляется на сторону сервера, он будет обнаружен валидатором на сервисном уровне. В обоих случаях пользователю будет выдано исключение.
Однако я думаю, что это не лучшее решение. Итак, я хотел бы получить один.
РЕДАКТИРОВАТЬ. В любом случае я использую аннотации для наложения ограничений на поля сущностей, чтобы Hibernate мог использовать их для проверки перед сохранением объекта.
