Hibernate. Third, we instruct the entity factory to scan for the domain objects with
ORM annotations under the package com.apress.prospring3.ch10.domain
(specified by the <property name="packagesToScan"> tag). Note that this feature has
been available only since Spring 3.1, and with the support of domain class scanning,
you can skip the definition of the persistence unit in the META-INF/persistence.xml
file. Finally, the jpaProperties property provides configuration details for the
persistence provider, Hibernate. You will see that the configuration is just the same
as those we used in Chapter 9. So, we will skip the explanation here.
ORM Mapping Using JPA Annotations
As mentioned, Hibernate influenced the design of JPA a lot. For the mapping annotations, they are so
close that the annotations we used in Chapter 9 for mapping the domain objects to the database are the
same in JPA.
If you take a look at the domain classes source code in Chapter 9, you will see that all mapping
annotations are under the package javax.persistence, which means those annotations are already JPA
compatible. So, we didn't repeat the code in this chapter. Please refer to Chapter 9 for the mappings and
explanations.
Eliminating the DAO Layer
As you already saw in Chapter 8 and Chapter 9, when we use JDBC and Hibernate for programming data
access logic, we use the DAO pattern. The intention of the DAO pattern is to wrap the different
implementations of data access logic into its own layer so that those details are totally hidden from the
service layer and the service layer is not aware of whether we are using JDBC or Hibernate in getting the
data access job done.
However, after JPA was born, the justification of the existence of a DAO layer for data access logic
becomes questionable. Because JPA was designed to be a standard in which the underlying persistence
provider can be switched easily, there's simply no strong reason to maintain the data access logic in a
separate DAO layer. So, nowadays, many JEE developers who standardized on JPA as the data access
layer have chosen to eliminate the DAO layer and have the EntityManager directly injected into the
service layer.
The justification of the existence of a DAO layer in JEE applications is still under hot debate, but one
fact is that getting rid of the DAO layer simplifies the application architecture a lot, which is one of the
main benefits. In this chapter and in the sample application, we have chosen to eliminate the DAO layer
for the JPA implementation and instead provide the implementation of service layer by directly injecting
the entity manager into the service layer classes.
However, it will not make a big difference if you or your development team still prefer the existence
of the DAO layer. You can still program all the JPA logic into a separate DAO layer and have it injected
into the service layer.
Injecting EntityManager into Service Layer Classes
For JDBC and Hibernate support, Spring provides the corresponding template classes JdbcTemplate and
HibernateTemplate (although they are explicitly deprecated in favor of using Hibernate's Session
interface directly, as we discussed in Chapter 9), which greatly simplifies the code we need to develop.
For JPA, Spring also used to provide the JpaTemplate class. However, as JPA 2 has become much more
mature, the Spring development team has found that it is unnecessary to provide such a template. If you
refer to Spring Framework 3.1's JavaDoc, you will see that the class JpaTemplate is deprecated, and for
JPA 2, Spring recommends that you use the EntityManager directly.
Search WWH :
