Hibernate SessionFactory vs. JPA EntityManagerFactory

Sono nuovo di Hibernate e non sono sicuro se utilizzare un Hibernate SessionFactoryo un JPA EntityManagerFactoryper creare un Hibernate Session.

Qual è la differenza tra questi due? Quali sono i pro e i contro dell'utilizzo di ognuno di questi?

Preferire EntityManagerFactorye EntityManager. Sono definiti dallo standard JPA.

SessionFactorye Sessionsono specifici dell'ibernazione. La EntityManagerinvoca la sessione di ibernazione sotto il cofano. E se hai bisogno di alcune funzionalità specifiche che non sono disponibili in EntityManager, puoi ottenere la sessione chiamando:

Session session = entityManager.unwrap(Session.class);

Voglio aggiungere a questo che puoi anche ottenere la sessione di Hibernate chiamando il getDelegate()metodo da EntityManager.

ex:

Session session = (Session) entityManager.getDelegate();

Preferisco l' EntityManagerAPI JPA2 rispetto a SessionFactory, perché sembra più moderno. Un semplice esempio:

JPA:

@PersistenceContext
EntityManager entityManager;

public List<MyEntity> findSomeApples() {
  return entityManager
     .createQuery("from MyEntity where apples=7", MyEntity.class)
     .getResultList();
}

SessionFactory:

@Autowired
SessionFactory sessionFactory;

public List<MyEntity> findSomeApples() {
  Session session = sessionFactory.getCurrentSession();
  List<?> result = session.createQuery("from MyEntity where apples=7")
      .list();
  @SuppressWarnings("unchecked")
  List<MyEntity> resultCasted = (List<MyEntity>) result;
  return resultCasted;
}

Penso che sia chiaro che il primo sembra più pulito ed è anche più facile da testare perché EntityManager può essere facilmente deriso.

L'uso dell'approccio EntityManagerFactory ci consente di utilizzare le annotazioni del metodo di callback come @PrePersist, @ PostPersist, @ PreUpdate senza alcuna configurazione aggiuntiva.

L'uso di callback simili durante l'utilizzo di SessionFactory richiederà ulteriori sforzi.

I documenti di ibernazione correlati sono disponibili qui e qui .

Discussione relativa alla domanda SOF e discussione del forum di primavera

SessionFactory vs. EntityManagerFactory

Come ho spiegato nella Guida dell'utente di Hibernate , Hibernate SessionFactoryestende l'APP EntityManagerFactory, come illustrato dal diagramma seguente:

Quindi, SessionFactoryè anche un JPA EntityManagerFactory.

Sia il SessionFactoryche il EntityManagerFactorycontengono i metadati di mappatura dell'entità e consentono di creare un ibernazione Sessiono un EntityManager.

Session vs. EntityManager

Proprio come il SessionFactorye EntityManagerFactory, l'ibernato Sessionestende l'APP EntityManager. Quindi, tutti i metodi definiti da EntityManagersono disponibili in Hibernate Session.

Il Sessione il `EntityManager traducono le transizioni dello stato dell'entità in istruzioni SQL, come SELECT, INSERT, UPDATE e DELETE.

Bootstrap Hibernate vs. JPA

Quando si avvia il bootstrap di un'applicazione JPA o Hibernate, sono disponibili due opzioni:

1. È possibile eseguire il bootstrap tramite il meccanismo nativo di Hibernate e creare un SessionFactorytramite BootstrapServiceRegistryBuilder. Se stai usando Spring, il bootstrap di Hibernate viene eseguito tramite LocalSessionFactoryBean, come illustrato da questo esempio GitHub .
2. In alternativa, è possibile creare un JPA EntityManagerFactorytramite la Persistenceclasse o il EntityManagerFactoryBuilder. Se stai usando Spring, il bootstrap JPA viene eseguito tramite LocalContainerEntityManagerFactoryBean, come illustrato da questo esempio GitHub .

Il bootstrap tramite JPA deve essere preferito. Questo perché JPA FlushModeType.AUTOè una scelta molto migliore rispetto all'eredità FlushMode.AUTO, che interrompe la coerenza di lettura e scrittura per le query SQL native .

Non imballare JPA in ibernazione

Inoltre, se si avvia bootstrap tramite JPA e si è iniettato EntityManagerFactorytramite l' @PersistenceUnitannotazione:

@PersistenceUnit
private EntityManagerFactory entityManagerFactory;

Puoi facilmente accedere al sottostante Sessionfactoryusando il unwrapmetodo:

SessionFactory sessionFactory = entityManagerFactory.unwrap(SessionFactory.class);

Lo stesso può essere fatto con l'APP EntityManager. Se si inietta EntityManagertramite l' @PersistenceContextannotazione:

@PersistenceContext
private EntityManager entityManager;

Puoi facilmente accedere al sottostante Sessionusando il unwrapmetodo:

Session session = entityManager.unwrap(Session.class);

Conclusione

Pertanto, è necessario eseguire il bootstrap tramite JPA, utilizzare EntityManagerFactorye EntityManagere scartarli solo sulle interfacce Hibernate associate quando si desidera accedere ad alcuni metodi specifici di Hibernate non disponibili in JPA, come recuperare l'entità tramite il suo identificatore naturale .

Utilizzando EntityManager, il codice non è più strettamente accoppiato con l'ibernazione. Ma per questo, in uso dovremmo usare:

javax.persistence.EntityManager

invece di

org.hibernate.ejb.HibernateEntityManager

Allo stesso modo, per EntityManagerFactory, utilizzare l'interfaccia javax. In questo modo, il codice è liberamente accoppiato. Se esiste un'implementazione JPA 2 migliore di quella in letargo, la commutazione sarebbe facile. In casi estremi, potremmo digitare cast in HibernateEntityManager.

EntityManagerFactory è l'implementazione standard, è la stessa in tutte le implementazioni. Se esegui la migrazione del tuo ORM per qualsiasi altro provider come EclipseLink, non ci saranno cambiamenti nell'approccio alla gestione della transazione. Al contrario, se si utilizza la factory di sessione di hibernate, è legata alle API di ibernazione e non può migrare verso un nuovo fornitore.

L'interfaccia EntityManager è simile a sessionFactory in ibernazione. EntityManager nel pacchetto javax.persistance ma session e sessionFactory in org.hibernate.Session / sessionFactory pacchetto.

Il gestore entità è specifico per JPA e session / sessionFactory sono specifici di ibernazione.