Lesson 2: Overview of Spring Data JPA
In this lesson, we’ll start analyzing Spring Data and Spring Data JPA, with the final objective of clearly understanding the purpose of these data-access projects, in what cases we can make use of these solutions, and when they may not be totally suitable hence we should look for a better resolution.
2. Lesson Notes
2.1. Spring Data
First, let’s differentiate Spring Data and Spring Data JPA.
Simply put, Spring Data is a family of projects, all related to data access aspects. The goal of this umbrella project is to offer a familiar and consistent Spring-based model for data access whilst providing submodules to cover any specific scenario we might have to deal with.
Spring Data Commons is the core subproject, the foundation for all the other modules which include, among others:
- Spring Data JDBC
- Spring Data LDAP
- Spring Data MongoDB
- Spring Data Redis
- and, of course, Spring Data JPA
2.2. Spring Data JPA
Spring Data JPA has the particular objective of providing convenient support for JPA-based data access layers.
This persistence framework offers several useful features, but the most outstanding one which makes it a widely used solution is the possibility of easily implementing JPA-based repositories, reducing the boilerplate of writing, preparing, and executing queries, as well as paginating, and auditing.
We can have fully working data access functionality with only a few lines of code and without having to write a single SQL query.
Concretely, with Spring Data JPA we can create a repository interface including different methods that follow a particular naming pattern and the framework will build up their implementation automatically for us:
But this is just a preview, as we'll get into that later in the course.
2.3. Some Considerations
Of course, every solution has some drawbacks. In this case, we’re delegating a lot of functionality to the framework, and whenever that happens, we lose some control over what is finally executed.
If we add to this the fact that the library has to be flexible to adapt to many different scenarios, then we might find that, in some cases, this doesn’t represent the optimal solution from a performance perspective.
This is actually a potential issue inherent to the ORM technique used by JPA.
It's worth mentioning that this is not a common issue since this is, after all, a tested and well-designed solution that offers different alternatives to customize the behavior and overcome most problems we might come across.
The takeaway here is this is a very powerful and useful solution, suitable for most projects, and definitely better than writing a lot of boilerplate manually.
It provides the tools and the flexibility to address most scenarios, but it’s important to understand certainly not all scenarios.
Simply put, we don’t necessarily have to only use Spring Data JPA as the single solution across the board.
There might be edge cases, a few exceptional queries, or persistence procedures where it makes sense to use a different approach, maybe lower level JPA customizations or even some JDBC operations, and that’s totally fine.
We have to be analytical to find the best tool for the job and decide when it makes sense to mix different solutions.
As you can imagine this requires having a broad knowledge of the persistence framework features and understanding what is going on behind the scenes, which is actually what we finally pursue in this course.