Manejo de objetos persistentes

6.4 Manejo de objetos persistentes

Las clases presistentes son clases en una aplicación que implementan las entidades del problema empresarial (por ejemplo, Customer y Order en una aplicación de comercio electrónico). No se considera que todas las instancias de una clase persistente estén en estado persistente. Por ejemplo, una instancia puede ser transitoria o separada.

Hibernate funciona mejor si estas clases siguen algunas reglas simples, también conocidas como el modelo de programación POJO (Plain Old Java Object). Sin embargo, ninguna de estas reglas son requerimientos rígidos. De hecho, Hibernate3 asume muy poco acerca de la naturaleza de sus objetos persistentes. Puede expresar un modelo de dominio en otras formas (por ejemplo, utilizando árboles de instancias de Map).

Ejemplo simple de POJO

La mayoría de aplicaciones Java requieren una clase persistente que represente a los felinos. Por ejemplo:

package eg;

import java.util.Set;

import java.util.Date;

public class Cat {

private Long id; // identifier

private Date birthdate;

private Color color;

private char sex;

private float weight;

private int litterId;

private Cat mother;

private Set kittens = new HashSet();

private void setId(Long id) {

this.id=id;

}

public Long getId() {

return id;

}

void setBirthdate(Date date) {

birthdate = date;

}

public Date getBirthdate() {

return birthdate;

}

void setWeight(float weight) {

this.weight = weight;

}

public float getWeight() {

return weight;

}

public Color getColor() {

return color;

}

void setColor(Color color) {

this.color = color;

}

void setSex(char sex) {

this.sex=sex;

}

public char getSex() {

return sex;

}

void setLitterId(int id) {

this.litterId = id;

}

public int getLitterId() {

return litterId;

}

void setMother(Cat mother) {

this.mother = mother;

}

public Cat getMother() {

return mother;

}

void setKittens(Set kittens) {

this.kittens = kittens;

}

public Set getKittens() {

return kittens;

}

public void addKitten(Cat kitten) {

kitten.setMother(this);

kitten.setLitterId( kittens.size() );

kittens.add(kitten);

}

}

En las siguientes secciones vamos a explorar en mayor detalle las cuatro reglas principales de las clases persistentes.

Implemente un constructor sin argumentos

Cat tiene un contructor sin argumentos. Todas las clases persistentes deben tener un constructor predeterminado (el cual puede ser no-público) de modo que Hibernate pueda instanciarlas usando Constructor.newInstance(). Le recomendamos contar con un constructor por defecto con al menos una visibilidad de paquete para la generación de proxies en tiempo de ejecución en Hibernate.

Proporcione una propiedad identificadora (opcional)

Cat tiene una propiedad llamada id. Esta propiedad mapea a la columna de la llave principal de la tabla de la base de datos. La propiedad podría llamarse de cualquier manera y su tipo podría haber sido cualquier tipo primitivo, cualquier tipo de "wrapper" primitivo, java.lang.String o java.util.Date. Si su tabla de base de datos heredada tiene claves compuestas, puede utilizar una clase definida por el usuario con propiedades de estos tipos

La propiedad identificadora es estrictamente opcional. Puede olvidarla y dejar que Hibernate siga internamente la pista de los identificadores del objeto. Sin embargo, no recomendamos que esto suceda.

De hecho, algunas funcionalidades se encuentran disponibles sólamente para clases que declaran una propiedad identificadora:

• Session.saveOrUpdate()

• Session.merge()

Le recomendamos que declare propiedades identificadoras nombradas-consistentemente en clases persistentes. y que utilice un tipo nulable (por ejemplo, no primitivo).

Prefiera las clases no finales

Un aspecto central de Hibernate, los proxies, dependen de que las clases persistentes sean no finales o de la implementación de una interfaz que declare todos los métodos públicos.

Con Hibernate puede persistir las clases finales que no implementen una interfaz. Sin embargo, no podrá utilizar proxies para recuperación perezosa de asociaciones, lo cual limitará sus opciones para afinar el rendimiento.

También debe evitar el declarar métodos public final en las clases no-finales. Si quiere utilizar una clase con un método public final, debe deshabilitar explícitamente el uso de proxies estableciendo lazy="false".

Declare métodos de acceso y de modificación para los campos persistentes

Cat declara métodos de acceso para todos sus campos persistentes. Muchas otras herramientas ORM persisten directamente variables de instancia. Es mejor proporcionar una indirección entre el esquema relacional y las estructuras de datos internos de la clase. Por defecto, Hibernate persiste las propiedades del estilo JavaBeans, y reconoce los nombres de método de la forma getFoo, isFoo y setFoo. De ser necesario, puede cambiarse al acceso directo a campos para propiedades específicas.

No es necesario declarar públicas las propiedades. Hibernate puede persistir una propiedad con un par get / set protected o private.

Implementación de herencia

Una subclase también tiene que cumplir con la primera y la segunda regla. Hereda su propiedad identificadora de la superclase Cat. Por ejemplo:

package eg;

public class DomesticCat extends Cat {

private String name;

public String getName() {

return name;

}

protected void setName(String name) {

this.name=name;

}

}

Implementando equals() y hashCode()

Tiene que sobrescribir los métodos equals() y hashCode() si:

• piensa poner instancias de clases persistentes en un Set (la forma recomendada de representar asociaciones multivaluadas); y

• piensa utilizar reasociación de instancias separadas.

Hibernate garantiza la equivalencia de identidad persistente (fila de base de datos) y de identidad Java sólamente dentro del ámbito de una sesión en particular. De modo que en el momento en que mezcla instancias recuperadas en sesiones diferentes, tiene que implementar equals() y hashCode() si desea tener una semántica significativa para Sets.

La forma más obvia es implementar equals()/hashCode() comparando el valor identificador de ambos objetos. Si el valor es el mismo, ambos deben ser la misma fila de la base de datos ya que son iguales. Si ambos son agregados a un Set, sólo tendremos un elemento en el Set). Desafortunadamente, no puede utilizar este enfoque con identificadores generados. Hibernate sólo asignará valores identificadores a objetos que son persistentes; una instancia recién creada no tendrá ningún valor identificador. Además, si una instancia no se encuentra guardada y está actualmente en un Set, al guardarla se asignará un valor identificador al objeto. Si equals() y hashCode() están basados en el valor identificador, el código hash podría cambiar, rompiendo el contrato del Set. Consulte el sitio web de Hibernate y allí encontrará una discusión completa sobre este problema. Este no es un problema de Hibernate, sino de la semántica normal de Java de identidad de objeto e igualdad.

Le recomendamos implementar equals() y hashCode() utilizando igualdad de clave empresarial (Business key equality). Igualdad de clave empresarial significa que el método equals() sólamente compara las propiedades que forman la clave empresarial. Esta es una clave que podría identificar nuestra instancia en el mundo real (una clave candidata natural):

public class Cat {

public boolean equals(Object other) {

if (this == other) return true;

if ( !(other instanceof Cat) ) return false;

final Cat cat = (Cat) other;

if ( !cat.getLitterId().equals( getLitterId() ) ) return false;

if ( !cat.getMother().equals( getMother() ) ) return false;

return true;

}

public int hashCode() {

int result;

result = getMother().hashCode();

result = 29 * result + getLitterId();

return result;

}

}

Modelos dinámicos

Las entidades persistentes no necesariamente tienen que estar representadas como clases POJO o como objetos JavaBean en tiempo de ejecución. Hibernate también soporta modelos dinámicos (utilizando Mapeos de Mapeos en tiempo de ejecución) y la representación de entidades como árboles de DOM4J. No escriba clases persistentes con este enfoque, sólamente archivos de mapeo.

Los siguientes ejemplos demuestran la representación utilizando Mapeos. Primero, en el archivo de mapeo tiene que declararse un entity-name en lugar de, o además de un nombre de clase:

...