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:
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:
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: [java]public interface EmployeeRepository extends JPARepository[/java] Given some Spring magic, an implementation will be provided at runtime with the following methods:
void deleteInBatch(Iterable entities)
List findAll(Sort sort)
List save(Iterable entities)
Employee saveAndFlush(Employee entity)
Page findAll(Pageable pageable)
Iterable findAll(Sort sort)
void delete(ID id)
void delete(Iterable entities)
void delete(Employee entity)
boolean exists(Long id)
Iterable findAll(Iterable ids)
Employee findOne(Long id)
Iterable save(Iterable entities)
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):
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:
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.
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. To go further: