Jul 1, 2012 / JPA, PERSISTENCE, SPRING DATA

Easier JPA with Spring Data JPA

Database access in Java went through some steps:

at first, pure JDBC
proprietary frameworks
standards such as EJB Entities and JDO
OpenSource frameworks such as Hibernate and EclipseLink (known as TopLink at the time)

When JPA was finally released, it seemed my wishes came true. At last, there was a standard coming from the trenches to access databases in Java

Unfortunately, JPA didn’t hold its promises when compared to Hibernate: for example, you don’t have Query by Example. Even worse, in its first version, JPA didn’t provide simple features like Criteria, so that even simple queries would have to be implemented through JPQL and thus achieved with String concatenation. IMHO, this completely defeated ORM purposes.

JPA2 to the rescue

At last, JPA2 supplies something usable in a real-world application. And yet, I feel there’s still so much boilerplate code to write a simple CRUD DAO:

public class JpaDao {

    @PersistenceContext
    private EntityManager em;

    private Class managedClass;

    private JpaDao(Class managedClass) {
        this.managedClass = managedClass;
    }

    public void persist(E entity) {
        em.persist(entity);
    }

    public void remove(E entity) {
        em.remove(entity);
    }

    public E findById(PK id) {
        return em.find(managedClass, id);
    }
}

Some would (and do) object that in such a use-case, there’s no need for a DAO: the EntityManager just needs to be injected in the service class and used directly. This may be a relevant point-of-view, but only when there’s no query for as soon as you go beyond that, you need to separate between data access and business logic.

Boilerplate code in JPA2

Two simple use-cases highlight the useless boilerplate code in JPA 2: @NamedQuery and simple criteria queries. In the first case, you have to get the handle on the named query through the entity manager, then set potential parameters like so:

Query query = em.createNamedQuery("Employee.findHighestPaidEmployee");

In the second, you have to implement your own query with the CriteriaBuilder:

CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery query = builder.createQuery(Person.class);
Root fromPerson = query.from(Person.class);
return em.createQuery(query.select(fromPerson)).getResultList();

IMHO, these lines of code bring nothing to the table and just clutter our own code. By chance, some time ago, I found project Hades, a product which was based on this conclusion and wrote simple code for you.

Spring Data JPA

Given the fate of some excellent OpenSource projects, Hades fared much better since it has been brought into the Spring ecosystem under the name Spring Data JPA. Out of the box, SDJ provides DAOs that have advanced CRUD features. For example, the following interface can be used as-is:

public interface EmployeeRepository extends JPARepository

Given some Spring magic, an implementation will be provided at runtime with the following methods:

void deleteAllInBatch()
void deleteInBatch(Iterable<Employee> entities)
List<Employee> findAll()
List<Employee> findAll(Sort sort)
void flush()
<S extends Employee> List<S> save(Iterable<S> entities)
Employee saveAndFlush(Employee entity)
Page<Employee> findAll(Pageable pageable)
Iterable<Employee> findAll(Sort sort)
long count()
void delete(ID id)
void delete(Iterable<? extends Employee> entities)
void delete(Employee entity)
void deleteAll()
boolean exists(Long id)
Iterable<Employee> findAll()
Iterable<Employee> findAll(Iterable ids)
Employee findOne(Long id)
<S extends Employee> Iterable<S> save(Iterable<S> entities)
<S extends Employee> S save(S entity)

Yes, SDJ provides you with a generic DAO, like so many frameworks around but here, wiring into the underlying implementation is handled by the framework, free of charge. For those that don’t need them all and prefer the strict minimum, you can also use the following strategy, where you have to choose the methods from the list above (and use the annotation):

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {
    long count();
    Employee save(Employee employee);
}

It sure is nice, but the best is yet to come. Remember the two above use-cases we had to write on our own? The first is simply handled by adding the unqualified query name to the interface like so:

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {
    ...
    Employee findHighestPaidEmployee();
}

The second use-case, finding all employees, is provided in the JPA repository. But let’s pretend for a second we have a WHERE clause, for example on the first name. SDJ is capable of handling simple queries based on the method name:

@RepositoryDefinition(domainClass = Employee.class, idClass = Long.class)
public interface EmployeeRepository {
    ...
    List findByLastname(String firstName);
}

We had to code only an interface and its methods: no implementation code nor metamodel generation was involved! Don’t worry, if you need to implement some complex queries, SDJ let you wire your own implementation.

Conclusion

If you’re already a Spring user, Spring Data JPA is really (really!) a must. If you’re not, you’re welcome to test it to see its added value by yourself. IMHO, SDJ is one of the reason JavaEE has not killed Spring yet: it bridged the injection part, but the boilerplate code is still around every corner.

This article is not a how-to but a teaser to let you into SDJ. You can find the sources for this article here, in Maven/Eclipse format.

For those that aren’t into JPA yet, there’s Data JDBC; for those that are well beyond that (think Big Data); there’s a Data Hadoop. Check all of Spring Data projects!

To go further:

Follow @nicolas_frankel