1. Goal

In this lesson, we’ll start analyzing Spring Data and Spring Data JPA. Our objective will be to clearly understand 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 so we know to look for a better resolution.

2. Lesson Notes

2.1. Spring Data

First, let’s differentiate between 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, while providing submodules to cover any specific scenario we might have to deal with.

Spring Data Commons is the core subproject. It’s 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 ones that make it a widely used solution are 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.

Furthermore, with Spring Data JPA, we can create a repository interface that includes different methods that follow a particular naming pattern, and the framework will build up their implementation automatically for us:

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’s 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 isn’t a common issue, since it is, after all, a tested and well-designed solution that offers different alternatives to customize the behavior, and overcome most problems we might run into.

2.4. Conclusions

The takeaway here is that 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 flexibility to address most scenarios, but it’s important to understand this doesn’t mean all scenarios.

Simply put, we don’t necessarily have to use only Spring Data JPA as our 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. This could mean 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 what we will pursue in this course. 

3. Resources

- Spring Data Overview

- Spring Data JPA Overview

- Spring Data JPA Reference