SpringSource have recently released the first milestone of Spring Data JPA project. What are its features? and how can we use them. Spring framework already provides support to build a JPA based data access layer. So, what does Spring Data adds to it. I used it for one small application and found significant reduction of code. In this post we will use an Employee entity and EmployeeRepository as an example to work with Spring Data JPA.
We have a domain Employee :
We also have a EmployeeRepository handling the Employee entities. The interface and the implementation are given below.
the client need to decide whether to call merge(…) or persist(…) on the EntityManager. We use the id-field of the Employee to decide whether we consider an Employee object as new or not.
Spring Data JPA provides a repository programming model that starts with an interface per managed domain object. That means for the Employee domain there is an Interface such as EmployeeRepository .
by extending JpaRepository we get generic CRUD methods into our type that allows working with Employees. This also allow the Spring Data JPA repository infrastructure to scan the classpath for this interface and create a Spring bean for it.
To have Spring create a bean that implements this interface, we need to use the Spring JPA namespace and activate the repository support using the appropriate element:
This scans all the package below
com.inphina.springdata for interfaces extending
JpaRepository and creates a spring bean backed by an implementation of
Now lets use a bit of Spring Data help in reducing the EmployeeRepositoryImpl code. We change the interface EmployeeRepository to this:
The EmployeeRepositoryImpl can then implement
findByName(String name, int page, int pageSize) and
Employee save(Employee employee); as shown in the code below.
Here we simply delegate the call to save(…) to the repository. By default the repository implementation considers an entity new if its id property is null similar to the first code listing of
Spring Data JPA provides an abstraction consisting of two interfaces: Pageable (to capture pagination request information) as well as Page (to capture the result as well as meta-information). We can add the
findByName in the interface itself. The need for the interface implementation is not required now. This is how the interface will look after the changes.
To summarize we have seen that there is significant reduction of the code. After refactoring what remains is one interface and a XML declaration. Spring Data JPA does looks similar to Hades where simple queries can be generated from method names. However we might come to see integration of QueryDsl in near future.
3 thoughts on “Working With Spring Data JPA4 min read”
EmployeeRepositoryImpl : implementing EmployeeRepository interface that means we need to override all methods in Parent interface(JpaRepository) otherwise won’t compile the code.
But if we override all methods of JpaRepository then what is the use of JpaRepository.
No you don’t have to implement the methods in JpaRepository…. you need to do so only for the ones you are going to use… like in the above example only save() and findByName() methods have been overridden.
Comments are closed.