Creating repositories that use the Java Persistence API is a cumbersome process that takes a lot of time and requires a lot of boilerplate code. We can eliminate some boilerplate code by following these steps:
- Create an abstract base repository class that provides CRUD operations for entities.
- Create the concrete repository class that extends the abstract base repository class.
The problem of this approach is that we still have to write the code that creates our database queries and invokes them. To make matters worse, we have to do this every time when we want to create a new database query. This is a waste of time.
What would you say if I would tell you that we can create JPA repositories without writing any boilerplate code?
The odds are that you might not believe me, but Spring Data JPA helps us to do just that. The website of the Spring Data JPA project states that:
Implementing a data access layer of an application has been cumbersome for quite a while. Too much boilerplate code has to be written to execute simple queries as well as perform pagination, and auditing. Spring Data JPA aims to significantly improve the implementation of data access layers by reducing the effort to the amount that’s actually needed. As a developer you write your repository interfaces, including custom finder methods, and Spring will provide the implementation automatically
This blog post provides an introduction to Spring Data JPA. We will learn what Spring Data JPA really is and take a quick look at the Spring Data repository interfaces.
Let’s get started.
What Spring Data JPA Is?
Spring Data JPA is not a JPA provider. It is a library / framework that adds an extra layer of abstraction on the top of our JPA provider. If we decide to use Spring Data JPA, the repository layer of our application contains three layers that are described in the following:
- Spring Data JPA provides support for creating JPA repositories by extending the Spring Data repository interfaces.
- Spring Data Commons provides the infrastructure that is shared by the datastore specific Spring Data projects.
- The JPA Provider implements the Java Persistence API.
The following figure illustrates the structure of our repository layer:
Additional Reading:
At first it seems that Spring Data JPA makes our application more complicated, and in a way that is true. It does add an additional layer to our repository layer, but at the same time it frees us from writing any boilerplate code.
That sounds like a good tradeoff. Right?
Introduction to Spring Data Repositories
The power of Spring Data JPA lies in the repository abstraction that is provided by the Spring Data Commons project and extended by the datastore specific sub projects.
We can use Spring Data JPA without paying any attention to the actual implementation of the repository abstraction, but we have to be familiar with the Spring Data repository interfaces. These interfaces are described in the following:
First, the Spring Data Commons project provides the following interfaces:
- The Repository<T, ID extends Serializable> interface is a marker interface that has two purposes:
- It captures the type of the managed entity and the type of the entity’s id.
- It helps the Spring container to discover the “concrete” repository interfaces during classpath scanning.
- The CrudRepository<T, ID extends Serializable> interface provides CRUD operations for the managed entity.
- The PagingAndSortingRepository<T, ID extends Serializable> interface declares the methods that are used to sort and paginate entities that are retrieved from the database.
- The QueryDslPredicateExecutor<T> interface is not a “repository interface”. It declares the methods that are used to retrieve entities from the database by using QueryDsl Predicate objects.
Second, the Spring Data JPA project provides the following interfaces:
- The JpaRepository<T, ID extends Serializable> interface is a JPA specific repository interface that combines the methods declared by the common repository interfaces behind a single interface.
- The JpaSpecificationExecutor<T> interface is not a “repository interface”. It declares the methods that are used to retrieve entities from the database by using Specification<T> objects that use the JPA criteria API.
The repository hierarchy looks as follows:
That is nice, but how can we use them?
That is a fair question. The next parts of this tutorial will answer to that question, but essentially we have to follow these steps:
- Create a repository interface and extend one of the repository interfaces provided by Spring Data.
- Add custom query methods to the created repository interface (if we need them that is).
- Inject the repository interface to another component and use the implementation that is provided automatically by Spring.
Let’s move on and summarize what we learned from this blog post.
Summary
This blog post has taught us two things:
- Spring Data JPA is not a JPA provider. It simply “hides” the Java Persistence API (and the JPA provider) behind its repository abstraction.
- Spring Data provides multiple repository interfaces that are used for different purposes.
The next part of this tutorial describes how we can get the required dependencies.
If you want to know more about Spring Data JPA, you should read my Spring Data JPA Tutorial.
| Reference: | Spring Data JPA Tutorial: Introduction from our JCG partner Petri Kainulainen at the Petri Kainulainen blog. |
