Подтверждение сущностей Jpa: в процессе обслуживания или слушателями жизненного цикла

Question

Вопрос в том, где лучше (или другими словами: где вы предпочитаете) поместить бизнес-логику проверки сущностей Jpa.

Две идеи:

1. ВEntityListener, который перед сохранением или обновлением будет проверять сущность
2. в службе, предоставляющей доступ к постоянным методам jpa.

Есть плюсы и минусы обоих.При использовании подхода № 2 это проще проверить, так как вы можете просто посмеяться над провайдером jpa и проверить логику проверки.С другой стороны, при подходе № 1 валидация будет происходить в одно и то же время с валидациями, такими как @NotNull и т. Д.

Мне бы хотелось узнать, как вы решаете валидации в ваших проектах и ​​какой из них лучшеиди.

Спасибо.

Answer 1

Вот общее правило большого пальца, которому я следую:

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

Другими словами, если у вас есть ссылка на бин внутри другого, избегайте вставлять это ограничение @NotNull. Для этого лучше всего использовать сервисный уровень, поскольку вы обнаруживаете нарушение намного раньше и в более логичном месте (поскольку другие проверки бизнеса предполагают, что компоненты доступны).

В качестве примера рассмотрим следующую сущность (извинения за нее не будут компилироваться)

@Entity
public class User
{
   @Id
   private int id;
   @NotNull
   private String fullName;
   @NotNull
   private String email;
   private Set<Role> roles; //No bean validation constraints here.
   ...
   public boolean mapRoleToUser(Role role)
   { //Validation is done here. Including checks for a null role.
   }

}

@Entity
public class Role
{
  @Id
  private int id;
  @NotNull
  private String name;
}

Сервисный уровень в этом случае должен проверять, есть ли у пользователя роль или нет. Проверка на этапе pre-persist или pre-update слишком поздняя, ​​особенно когда существует отдельный сервисный уровень с бизнес-логикой и остальной бизнес-логикой в ​​доменной модели (к сожалению, я не видел достаточно хорошее приложение со всей логикой только в модели предметной области).