Configuring the JPA entity manager: We will discuss the types of
·
EntityManagerFactorys that Spring supports and how to configure the most
commonly used one, LocalContainerEntityManagerFactoryBean, in Spring's XML
configuration.
Data operations: We will go through how to implement basic database operations
·
in JPA. The concepts are quite like Hibernate. We will also discuss eliminating the
DAO layer in JPA applications.
Advanced query operations: We will discuss how to use native queries in JPA and
·
the strongly typed criteria API in JPA for more flexible query operations.
Introducing Spring Data JPA: We will discuss the Spring Data JPA project and
·
demonstrate how it can help simplify the development of data access logic.
Tracking entity changes and auditing: In database update operations, it's a
·
common requirement in keep track of the date an entity was created or last
updated and who made the change. Also, for critical information such as a
customer, a history table that stores each version of the entity is always required.
We will discuss how Spring Data JPA and Hibernate Envers (Hibernate Entity
Versioning System) can help ease the development of such logic.
Using JPA with Hibernate in the sample application: In the sample application, for
·
the JPA implementation, we have chosen to eliminate the DAO layer and inject the
entity manager directly into the service layer for executing the business logic. We
will discuss how JPA will be adopted in the sample application.
■ Note Like Hibernate, JPA supports the definition of mappings either in XML or in Java annotations. In this
chapter, we will focus on the annotation type of mapping, because its usage is much more popular than the
XML style.
Introducing JPA 2
Like many other Java specification requests (JSRs), the objective of the JPA 2.0 specification (JSR-317) is
to standardize the ORM programming model in both the JSE and JEE environments. It defines a
common set of concepts, annotations, interfaces, and other services that a JPA persistence provider
should implement (all of them are put under the javax.persistence package). When programming to
the JPA standard, developers have the option of switching the underlying provider at will, just like
switching to another JEE-compliant application server for applications developed on the JEE standards.
Within JPA, the core concept is the EntityManager interface, which comes from factories of type
EntityManagerFactory. The main job of EntityManager is to maintain a persistence context, in which all the
entity instances under management will be stored. The configuration of an EntityManager is defined as a
persistence unit, and there can be more than one persistence unit in an application. If you are using
Hibernate, you can think of the persistence context as the same as the Session interface, while the
EntityManagerFactory is the same as the SessionFactory. In Hibernate, the managed entities are stored in
the session, which you can directly interact with via Hibernate's SessionFactory or Session interface.
However, in JPA, you can't interact with the persistence context directly. Instead, you need to rely on
EntityManager to do the work for you.
JPQL is very similar to HQL, so if you have used HQL before, it shouldn't be difficult for you to
manage JPQL. However, in JPA 2, a strongly typed criteria API was introduced, which relies on the
Search WWH :
