¿Dónde pongo mis anotaciones de hibernación?¿Dónde poner anotaciones de hibernación?
¿Es la línea sobre mi variable de instancia? ¿O antes del getter? ¿O antes del setter? ¿O realmente no importa?
Muchas gracias
¿Dónde pongo mis anotaciones de hibernación?¿Dónde poner anotaciones de hibernación?
¿Es la línea sobre mi variable de instancia? ¿O antes del getter? ¿O antes del setter? ¿O realmente no importa?
Muchas gracias
Los coloca en el campo o en el getter. De la Guía de referencia de Hibernate Anotaciones:
2.2.1. Marking a POJO as persistent entity
(...)
Dependiendo de si realizar anotaciones campos o métodos, el tipo de acceso utilizado por Hibernate será campo o propiedad . La especificación EJB3 requiere que declare anotaciones en el tipo de elemento al que se accederá, es decir, el método getter si usa la propiedad acceso, el campo si usa el campo acceso. Se deben evitar las anotaciones de mezcla en los campos y métodos de . Hibernate adivinará el tipo de acceso desde la posición @Id o @EmbeddedId.
Usted también puede leer acerca de la anotación @Access
que permite forzar/anular el tipo de acceso (antes de Anotaciones de Hibernate 3.5 y JPA 2.0, que era parte de Hibernate Extensiones de anotación):
2.2.2.2. Access type
por defecto, el tipo de acceso de una clase jerarquía se define por la posición de la @Id o anotaciones @EmbeddedId. Si estas anotaciones están en un campo, , entonces solo se consideran los campos para la persistencia y se accede al estado a través del campo. Si hay anotaciones en un getter, solo se consideran persistentes los getters y se accede al estado a través del getter/setter . Eso funciona bien en la práctica y es el enfoque recomendado .
Nota
La colocación de las anotaciones dentro de una jerarquía de clases que ser consecuente (ya sea de campo o en propiedad) para ser capaz de determinar el valor por defecto el acceso tipo.Se recomienda mantener la estrategia de una sola ubicación de anotación en toda su aplicación .
Sin embargo, en algunas situaciones, es necesario a:
- fuerza el tipo de acceso de la jerarquía entidad
- anulación del tipo de acceso de una entidad específica en la jerarquía de clases
- anulación de la tipo de acceso de un tipo incrustable
El mejor caso de uso es un incrustable clase utilizada por varias entidades que podría no usar el mismo tipo de acceso. En este caso es mejor forzar el tipo de acceso en el nivel de clase incrustado.
(...)
En cuanto a los pros y los contras de ambos estilos, sugiero leer las siguientes preguntas:
¿Estás diciendo que si pongo las anotaciones en los campos, entonces los get/setters no se usarán para nada?¿Qué pasa con los campos simples (por ejemplo, cadenas) que no necesitan anotaciones? ¿Se usarán sus campos o sus adaptadores? – Chris
@Chris: si utiliza el acceso de campo, * Hibernate * omitirá el par get/set y accederá al campo directamente, utilizando la reflexión. Con respecto a la segunda parte de su comentario, todo depende del tipo de acceso - campo o propiedad - que será adivinado * desde la posición de @Id o @ EmbeddedId *. –
Desde entonces he descubierto que si uso el acceso de campo, me encuentro con todo tipo de problemas con los proxies que Hibernate usa para la carga diferida. Entonces getters/setters es! Woo hoo generación de código para el rescate! ¡Maldita sea esta cosa java es verbosa! – Chris
Todo depende de su estilo. Puede colocarlo antes del campo o antes del captador. En JPA estricto, las anotaciones sobre los incubadores se ignoran, pero no estoy seguro de si Hibernate sigue eso.
Debe ser coherente en toda su Entidad, o debe proporcionar una anotación @Access en la parte superior de la clase con un modo predeterminado y otro @Access antes de cada campo/propiedad que desea desviar del actual modo de clase
Hibernate es conocido por usar la reflexión de Java. Por lo tanto, realmente no importa si lo coloca por encima del archivado o por encima del captador.
Aquí está la descripción de algunas anotaciones importantes utilizadas en Hibernate.
@Entity: declares the class as an entity (i.e. a persistent POJO class)
@Table: is set at the class level; it allows you to define the table, catalog, and schema names for your entity mapping. If no @Table is defined the default values are used: the unqualified class name of the entity.
@Id: declares the identifier property of this entity.
@Generated Value: annotation is used to specify the primary key generation strategy to use. If the strategy is not specified by default AUTO will be used.
@Column: annotation is used to specify the details of the column to which a field or property will be mapped. If the @Column annotation is not specified by default the property name will be used as the column name.
Anotaciones mapeo herencia basada en Hibernate: Hay tres tipos de asignaciones de herencia os en hibernación. Son
1.Table por jerarquía Clase:
@Inheritance – Defines the inheritance strategy to be used for an entity class hierarchy. It is specified on the entity class that is the root of the entity class hierarchy.
@DiscriminatorColumn – Is used to define the discriminator column for the SINGLE_TABLE inheritance mapping strategies. The strategy and the discriminator column are only specified in the root of an entity class hierarchy or sub hierarchy in which a different inheritance strategy is applied
If the @DiscriminatorColumn annotation is missing, and a discriminator column is required, the name of the discriminator column defaults to "DTYPE" and the discriminator type to DiscriminatorType.STRING.
@DiscriminatorValue – Is used to specify the value of the discriminator column for entities of the given type. The DiscriminatorValue annotation can only be specified on a concrete entity class. If the DiscriminatorValue annotation is not specified and a discriminator column is used, a provider-specific function will be used to generate a value representing the entity type. If the DiscriminatorType is STRING, the discriminator value default is the entity name.
2.Table por sub jerarquía Clase:
@InheritanceType – Defines inheritance strategy options. JOINED is a strategy in which fields that are specific to a subclass are mapped to a separate table than the fields that are common to the parent class, and a join is performed to instantiate the subclass.
@PrimaryKeyJoinColumn – This annotation specifies a primary key column that is used as a foreign key to join to another table.
3.Table por jerarquía de clases Hormigón:
@InheritanceType – Defines inheritance strategy options. TABLE_PER_CLASS is a strategy to map table per concrete class.
@AttributeOverrides – This annotation is used to override mappings of multiple properties or fields.
@AttributeOverride – The AttributeOverride annotation is used to override the mapping of a Basic (whether explicit or default) property or field or Id property or field.
Espero que ayude a tener una idea sobre la anotación básica utilizada en hibenate.
He encontrado desde entonces que si uso el acceso de campo, me encuentro con todo tipo de problemas con los proxies que Hibernate usa para la carga diferida. Entonces getters/setters es! Woo hoo generación de código para el rescate! ¡Maldita sea esta cosa java es verbosa! – Chris
^De hecho, he estado luchando con problemas de carga diferida por un tiempo (configuré mis modelos para que usen la búsqueda ansiosa solo para que funcione mientras es solo un prototipo!) Pero sí, los getters/setters son muy importantes para la hibernación. – fabspro
Mi libro Hibernate hecho fácil me dice que lo coloque antes que los getters y setters. No se porque. –