JPA/Hibernate: Sub-Typing против стратегии 'шаблон'

Question

Ниже приведена иерархия типа JPA, в которой все поля данных (и связанные с ними геттеры) являются членами супертипа, а также абстрактные методы реализации бизнес -логики. Существует любое количество подтипов, которые реализуют эти абстрактные методы, не добавляя элементы данных, поэтому мы используем стратегию наследования одной таблицы, поэтому нам нужна только одна таблица в базе данных, чтобы подтвердить иерархию этого типа.

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

@Entity
@Table
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn
public abstract class SuperEntity {
  // Several fields and getters and setters
  ...
  // Abstract method declarations for business logic
  ...
}

@Entity
@DiscriminatorValue("some value")
public class SomeSubtype extends SuperEntity {
  // Implementations of abstract methods
  ...
}

Является ли это извращением концепции столбца дискриминатора в JPA/Hibernate?

Сотрудник утверждает, что, поскольку структура данных не варьируется от подтипа к подтипу, абстрактные методы и соответствующие реализации должны быть перемещены в что-то вроде подхода к схеме стратегии. Его представление лучше?

Answer 1

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

JPA и Hibernate в стороне, каждая книга дизайна OO, которую я когда -либо читал, начинается с «благосклонности по сравнению с наследством» для обмена поведением.

Предположим, что у вас был один объект данных, не могли бы вы поделиться объектом между каждой стратегией, не связанной с безручками, и работать на этом? Наличие меньше JPA/Hibernate легче для глаз, во всяком случае.