Ciclo de vida dos objetos Entity do Hibernate

Lista de Estados

E agora começa a diversão. Estudaremos os estados dos objetos Entidade. Você tem que pagar por tudo e também pelo uso do Hibernate. Você não acha que aprender HQL é um preço tão alto? Não, a vida é um pouco mais complicada.

Se você tiver algum tipo de objeto Entity que possa salvar no banco de dados usando o Hibernate, do ponto de vista do Hibernate, esse objeto pode ter quatro estados:

• transiente
• Persistente (ou Gerenciado)
• independente
• Removido

E para interessá-lo, adicionarei esta imagem a esta palestra:

transiente

Na verdade, tudo é muito mais simples do que parece, embora não sem nuances. Por exemplo, todo objeto Entity que você criou explicitamente usando o código Java e não carregou do banco de dados usando o Hibernate, tem um status Transient (transparente).

EmployeeEntity employee = new EmployeeEntity();

O status Transient significa que o Hibernate não tem idéia sobre este objeto, e nenhuma ação no objeto afeta o Hibernate, nem o trabalho do Hibernate neste objeto.

Esses objetos também são chamados de POJO - Plain Old Java Object . O termo é freqüentemente usado como o oposto de vários objetos com comportamento complicado. Lembra dos objetos Moc que Mockito criou? Aqui eles não são POJO.

Se algum código de cliente funcionar com um objeto com o status Transitório, sua interação pode ser descrita por um esquema super simples:

Persistente ou Gerenciado

O próximo caso mais comum são os objetos relacionados ao mecanismo Hibernate. Seu status é chamado de Persistente (ou Gerenciado). Existem exatamente duas maneiras de obter um objeto com esse status:

• Carregar objeto do Hibernate.
• Salve o objeto no Hibernate.

Exemplos:

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

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

Esse objeto geralmente corresponde a algum tipo de registro no banco de dados, possui um ID e coisas do gênero. Este objeto é anexado à sessão do Hibernate e, em geral, pode ser representado não por um objeto real, mas por algum tipo de proxy.

É bem possível que após chamar o método session.load() , você receba de volta algum objeto stub (proxy), e todas as chamadas ao banco de dados serão realizadas somente após a chamada dos métodos deste objeto. Mas falaremos sobre esses detalhes um pouco mais tarde.

E a interação entre o código do cliente e o objeto no status Gerenciado pode ser descrita com a seguinte figura:

independente

O próximo estado é quando o objeto foi desanexado da sessão. Ou seja, uma vez que o objeto foi anexado à sessão do Hibernate, mas a sessão foi encerrada ou a transação finalizada, o Hibernate não monitora mais esse objeto.

Exemplo:

session.close();

session.evict(entity);

No primeiro exemplo, a sessão foi encerrada. No segundo caso, indicamos explicitamente que queremos desanexar o objeto da sessão usando o método evict() .

O novo esquema de interação código-objeto ficará assim:

E é aqui que fica interessante. Se o seu objeto foi obtido do Hibernate, é provável que você tenha recebido um proxy em vez de um objeto real. E esse objeto proxy, após se desconectar da sessão, lançará exceções quando seus métodos forem chamados.

Este é o problema mais comum para todos os iniciantes ao trabalhar com o Hibernate. Você precisa saber exatamente a qualquer momento a resposta para perguntas como esta quando estiver trabalhando com um objeto Entidade :

• Você tem um objeto real ou apenas um proxy de um objeto real?
• Você está atualmente em uma transação ou não?
• É uma transação de leitura/gravação ou uma transação somente leitura?
• O objeto é gerenciado pelo mecanismo LazyLoading?
• Quais partes do objeto já estão carregadas na memória e quais partes serão carregadas quando acessadas?
• Como seu objeto está conectado a objetos dependentes?

A boa notícia é que na maioria das vezes é óbvio. Mas você ainda precisa entender como tudo funciona sob o capô. Programação declarativa é o que é - você pode escrever código em 10 minutos, entender por que não funciona como deveria - em 10 horas :)

Removido

E o último estado que seu objeto Entidade pode ter é Removido. Como você provavelmente já adivinhou pelo nome, este é o estado de um objeto remoto.

Esse estado aparece devido ao fato de que, se você excluir algum objeto do banco de dados, o objeto Java não desaparecerá imediatamente em nenhum lugar.

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