Pregunta

La siguiente es una jerarquía de tipo anotada JPA, en la que todos los campos de datos (y getters y setters asociados) son miembros del supertipo junto con métodos abstractos para implementar la lógica empresarial. Hay cualquier número de subtipos que implementan estos métodos abstractos sin agregar miembros de datos, por lo tanto, utilizamos una estrategia de herencia de tabla única para que solo necesitemos una tabla en la base de datos para respaldar este tipo de jerarquía.

Lo he hecho de esta manera porque, según el contenido de los datos, hay diferentes comportamientos que deben implementarse para lograr un objetivo final.

@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
  ...
}

¿Es esta una perversión del concepto de la columna discriminadora en JPA/Hibernate?

Un compañero de trabajo argumenta que dado que la estructura de los datos no varía de subtipo a subtipo, los métodos abstractos y las implementaciones correspondientes deben moverse a algo como un enfoque de patrón de estrategia. ¿Es su noción mejor?

¿Fue útil?

Solución

Mejor es extremadamente subjetivo. Parece que la composición y las estrategias son una alternativa válida, y eso podría evitar que necesite mapear otra entidad para cada implementación de la lógica comercial.

JPA y Hibernate Dejando a un lado, cada libro de diseño OO que he leído comienza con "favorecer la composición sobre la herencia" para compartir el comportamiento.

Suponiendo que tenía un objeto de datos, ¿no podría compartir el objeto entre cada estrategia no hibernada y operar en eso? Tener menos JPA/Hibernate es más fácil a los ojos, en cualquier caso.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top