Ciclo de vida de los objetos de Entidad de Hibernate

Lista de Estados

Y ahora comienza la diversión. Estudiaremos los estados de los objetos Entidad. Tienes que pagar por todo, y por usar Hibernate también. ¿No crees que aprender HQL es un precio tan alto? No, la vida es un poco más complicada.

Si tiene algún tipo de objeto Entity que puede guardar en la base de datos usando Hibernate, entonces, desde el punto de vista de Hibernate, este objeto puede tener cuatro estados:

• Transitorio
• Persistente (o Administrado)
• Separado
• Remoto

Y para interesarle, agregaré esta imagen a esta conferencia:

Transitorio

De hecho, todo es mucho más sencillo de lo que parece, aunque no exento de matices. Por ejemplo, cada objeto Entity que creó explícitamente usando código Java y no cargó desde la base de datos usando Hibernate, tiene un estado Transitorio (transparente).

EmployeeEntity employee = new EmployeeEntity();

El estado Transitorio significa que Hibernate no tiene idea acerca de este objeto, y ninguna acción sobre el objeto afecta a Hibernate, ni el trabajo de Hibernate sobre este objeto.

Dichos objetos también se denominan POJO (Plain Old Java Object) . El término se usa a menudo como el opuesto de varios objetos con comportamiento engañoso. ¿Recuerdas los objetos Moc que creó Mockito? Aquí no son POJO.

Si algún código de cliente funciona con un objeto con el estado Transitorio, entonces su interacción puede describirse mediante un esquema súper simple:

Persistente o Administrado

El siguiente caso más común son los objetos relacionados con el motor de Hibernate. Su estado se llama Persistente (o Administrado). Hay exactamente dos formas de obtener un objeto con este estado:

• Cargar objeto desde Hibernate.
• Guardar objeto en Hibernate.

Ejemplos:

Employee employee = session.load(Employee.class, 1);

Employee employee = new Employee ();
session.save(employee);

Dicho objeto generalmente corresponde a algún tipo de registro en la base de datos, tiene una identificación y similares. Este objeto se adjunta a la sesión de Hibernate y, en general, no se puede representar mediante un objeto real, sino mediante algún tipo de proxy.

Es muy posible que después de llamar al método session.load() , obtenga algún objeto stub (proxy), y todas las llamadas a la base de datos se realicen solo después de llamar a los métodos de este objeto. Pero hablaremos de tales detalles un poco más tarde.

Y la interacción entre el código del cliente y el objeto en el estado Administrado se puede describir con la siguiente imagen:

Separado

El siguiente estado es cuando el objeto se ha separado de la sesión. Es decir, una vez que el objeto se adjuntó a la sesión de Hibernate, pero luego se cerró la sesión o finalizó la transacción, e Hibernate ya no monitorea este objeto.

Ejemplo:

session.close();

session.evict(entity);

En el primer ejemplo, la sesión estaba cerrada. En el segundo caso, hemos indicado explícitamente que queremos desvincular el objeto de la sesión mediante el método evict() .

El nuevo esquema de interacción código-objeto se verá así:

Y aquí es donde se pone interesante. Si su objeto se obtuvo de Hibernate, es probable que le hayan dado un proxy en lugar de un objeto real. Y este objeto proxy, después de desconectarse de la sesión, generará excepciones cuando se llame a sus métodos.

Este es el problema más común para todos los principiantes cuando trabajan con Hibernate. Necesitas saber exactamente en cualquier momento la respuesta a preguntas como esta cuando trabajas con un objeto Entity :

• ¿Tiene un objeto real o simplemente un proxy de un objeto real?
• ¿Está usted actualmente en una transacción o no?
• ¿Es una transacción de lectura y escritura o una transacción de solo lectura?
• ¿El objeto está administrado por el mecanismo LazyLoading?
• ¿Qué partes del objeto ya están cargadas en la memoria y qué partes se cargarán cuando se acceda a ellas?
• ¿Cómo se conecta su objeto a los objetos dependientes?

La buena noticia es que la mayoría de las veces es obvio. Pero aún necesita comprender cómo funciona todo debajo del capó. La programación declarativa es lo que es: puede escribir código en 10 minutos, comprender por qué no funciona como debería, en 10 horas :)

Remoto

Y el último estado que puede tener su objeto Entidad es Eliminado. Como probablemente ya haya adivinado por su nombre, este es el estado de un objeto remoto.

Este estado aparece debido al hecho de que si elimina algún objeto de la base de datos, el objeto Java no desaparecerá inmediatamente en ninguna parte.

Employee employee = session.load(Employee.class, 1);
//after loading the object's state is Persisted

session.remove(employee);
//after deletion, the state of the object is Removed

session.save(employee);
//and now Persisted again

session.close();
//and now the Detached state