Using the JPA repository

Posted on

Question :

Last Saturday I presented my CBT in college and saw that I need to improve the project presented. The system receives invoices in XML format and handles them. I took as a base the system in the company where I do internship. It uses Primefaces, JSF, Spring IoC, Hibernate.

I then started to read some things searched on Google, left me perhaps confused, but I will inform you what I understood.

The repository would be a class to fetch information from the database or the location where information was persisted. But in the case of JpaRepository it provides the connection to a certain class of Model with the possibility of persisting in the database.

Am I correct?

I’ve read that this implementation is a good one because DAO is abstracted by ORM of JPA. Then there would be no need to implement a DAO class.

I would like the idea of colleagues to know what is right to think and what is wrong.

And if using interface JpaRepository is it possible to make an abstract class for later my classes implemented as repository extend from it? And working together with service ?

Would there be any example code or link?


Answer :

In general you are correct.

Repository Pattern

Repository is a design pattern similar to DAO (Data Access Object) in that its purpose is to abstract data access in a generic way from its model. The difference is that the Repository tries to represent the data as a collection of elements, even remembering a Collection .

Spring Data Jpa

The Spring Data Jpa project makes it easy to implement the Repository pattern through AOP (Aspect Oriented Programming).

Using only one interface, Spring will dynamically “generate” the implementation of data access methods. Extending the JpaRepository interface is optional, but the advantage is it already comes with several generic CRUD methods and you do not need to reset all of them.

At first it may be a bit strange to use this Spring project. Who does not know AOP and how Spring Data works will waste some time looking for the implementation of the interfaces.

Creating new methods simply through signatures is very easy. Here’s an example:

public interface ClienteRepository extends JpaRepository<Cliente, Long> {
    Cliente findByNome(String nome);
    Page<Cliente> findByCidadeAndEstado(Cidade cidade, Estado, estado, Pageable pageable);

At first we can ask: what does Spring do with it?

First the findBy prefix in method names means that it will be a query method.

What comes next is as an expression that defines which attributes will be used as filters. In the first example, findByNome , means, search for the nome attribute using the value passed in the first parameter. In the second example, the generated query will use an expression with the AND operator, considering the attributes cidade and estado .

In addition, the special parameter of type Pageable says that the result will be paged. Note that the method return is a “customer page”.

See the documentation on creating queries for more details.

Alternatively, you can specify a JPA or any native query through the @Query annotation. See documentation .

JPA query example:

public interface UserRepository extends JpaRepository<User, Long> {

  @Query("select u from User u where u.firstname like %?1")
  List<User> findByFirstnameEndsWith(String firstname);


Native query example:

public interface UserRepository extends JpaRepository<User, Long> {
  @Query(value = "SELECT * FROM USERS WHERE EMAIL_ADDRESS = ?0", nativeQuery = true)
  User findByEmailAddress(String emailAddress);

Customizing Spring Data Jpa

There are basically two ways to further customize Spring Data JPA:

Creating a specific implementation

If for just one case you really need to do an implementation of methods, it is possible. For this, if you have an interface ClienteRepository :

  • Create a ClienteRepositoryCustom interface with the methods you want to implement.
  • Create a ClienteRepositoryImpl class in the same package by implementing this interface.
  • Make interface ClienteRepository extend interface ClienteRepositoryCustom
  • See the documentation .

    Creating a “generic” interface

    If you have methods that you want to have in all repositories but are not present in the JpaRepository interface, you can create a generic interface with these methods and make your repositories extend that interface.

    Replacing the JpaRepository implementation

    Well, all the magic has a trick behind the scenes. There is, yes, an implementation of it all and you can extend it to fit your goals.

    I even did this in a recent project to allow a dynamic search using a map, where each map entry is automatically added to the search clauses.

    I believe that describing the entire process is outside the scope of the response, as well as lengthening the content a lot. So I’ll leave the link to one of the articles I used to do the implementation is Customizing Spring Data JPA Repository .

    On the one hand, creating your extended version of JpaRepository is not very complicated, but I suggest you try to solve specific issues using the more specific approaches already mentioned. Think twice before creating or overwriting methods that affect all your classes.


    DAO is a design pattern that abstracts data persistence . A Repository is an abstraction of a collection of objects and their manipulation methods. The two can exist in one project. The DAO , Repository and DTO (Data Transfer Object) cracks can be considered a Unit of Work Work).

    A formal definition of DAO has the Oracle Web site: link . A translator can help.

    A general overview of JPA Repository can be found here: link .

    The JPA Repository is a special Repository implementation, but note that the Repository is concerned with exposing methods that handle collections, not database operations, such as DAO. In the case of the Spring JPA Repository, it proposes to do some things in automatic (search, insert, update), but still the focus is the manipulation of items in a collection.

    It may even be that the concepts get confused because there are people who implement a Repository with a DAO face (for example, putting a method called Update() in the Repository). The correct one, in the case of a repository completely integrated with a database, would be the repository to update this in a transparent way.


    Leave a Reply

    Your email address will not be published. Required fields are marked *