APP Mejor Práctica: Estático de búsqueda Entidades

imaginar, un Evento entidad hace referencia a un estado Entidad:APP Mejor Práctica: Estático de búsqueda Entidades

@Entity 
@Table(name = "event") 
public class Event() 
{ 
    @Id 
    @Column(name = "id", nullable = false) 
    private long id; 
    ... 

    @ManyToOne 
    @JoinColumn(name = "status_code", nullable = false) 
    private Status status; 
} 


@Entity 
@Table(name = "status") 
public class Status() 
{ 
    @Id 
    @Column(name = "code", nullable = false) 
    private String code; 

    @Column(name = "label", nullable = false, updatable = false) 
    private String label; 
}

estado se asigna a una pequeña mesa 'status'. El estado es una entidad de datos/búsqueda típica de referencia.

code label 
    ----- -------------- 
    CRD Created 
    ITD Initiated 
    PSD Paused 
    CCD Cancelled 
    ABD Aborted

no estoy seguro de si es una buena idea para modelar Estado como una entidad. Se siente más como una enumeración de constantes ...

Por mapeo Estado como una entidad, que pueda usar objetos de estado en código Java, y los valores de estado son igualmente presentes en la base de datos. Esto es bueno para informar.

Por otro lado, si quiero establecer un estado particular para un evento, no puedo simplemente asignar el estado constante que tengo en mente. Debo buscar primero la entidad correcta:

event.setStatus(entityManager.find(Status.class, "CRD"))

¿Puedo evitar el fragmento de código anterior? Estoy affraid para una reducción del rendimiento y se ve muy pesado ...

¿Tengo que modificar las cosas con atributos de sólo lectura?
¿Puedo precomprobar estas entidades de búsqueda y usarlas como constantes?
¿Echaba de menos una característica crucial de JPA?
...?

Todas las opiniones/sugerencias/recomendaciones son bienvenidas!

Gracias! J.

Fuente

2010-08-31 Jan

¿Puedo evitar el fragmento de código anterior? Me da miedo una penalización de rendimiento y parece muy pesado.

Bien, podría usar un enum en su lugar. Realmente no veo por qué no lo haces en realidad.

Pero si realmente desea usar una entidad, entonces sería un candidato perfecto para el almacenamiento en caché de segundo nivel y esto resolvería su problema de rendimiento.

Fuente

2010-08-31 22:35:08

Podría mostrar el estado del modelo como una enumeración. Esto permitiría una configuración limpia y eficiente de los valores de estado en un evento. Tanto el 'código' como la 'etiqueta' podrían modelarse como atributos. Eso también es genial. Sin embargo, ¿entiendo correctamente que la información de "etiqueta" no está disponible en la base de datos? Esto es un poco desafortunado para informes externos: herramientas fuera de mi aplicación Java que pueden querer acceder a la base de datos. ¿O pasé por alto algo? ¿Pueden los Enume ser mapeados a su propia tabla de base de datos también? – Jan

Tendré que echar un vistazo más de cerca al caché de segundo nivel. Por accidente, ¿conoce alguna herramienta que permita una fácil monitorización del caché de segundo nivel en Hibernate? – Jan

@ Jan Bien, no tendría la etiqueta en la base de datos con una enumeración. Pero realmente usaría 'Created',' Initiated', etc. en la enumeración, no en el código. De todos modos, de hecho es mejor para ti usar una entidad. Y en ese caso, el consejo de @Jörn es bueno. Aún así, esta entidad de solo lectura sería un candidato perfecto para el almacenamiento en caché L2. En cuanto a la supervisión, depende del proveedor de caché L2. –

Puede usar entityManager.getReference(Status.class, "CRD"), que podría no obtener la entidad de la base de datos si solo se usa para establecer una clave externa.

Fuente

2010-09-01 10:06:23

¡Bien! Ese es el tipo de pistas que estaba buscando. – Jan

APP Mejor Práctica: Estático de búsqueda Entidades

Respuesta

Cuestiones relacionadas