Using the JPA repository

Question

Last Saturday I presented my TCC in college and saw that I need to improve the presented project. The system receives tax notes in format XML and manipulates them. I based the system on the company where I work. We use Primefaces, JSF, Spring Ioc, Hibernate.

I then started reading some things searched in Google, left me maybe confused, but I will inform what I understood.

The repository would be a class to search for information in the database or at the location where the information was persisted. But in the case of JpaRepository it provides the link to a certain class of Model with possibility to persist in the database.

I am correct?

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

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

And if using the interface JpaRepository is it possible to make an abstract class to then extend my implemented classes as a repository? And work together with the service?

Would have some example code or link?

Answer 1

In general you are correct.

Repository Pattern

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

Spring Data Jpa

The Spring Data Jpa project facilitates implementation of the standard Repository through AOP (Aspect Oriented Programming - aspect-oriented programming).

Using only one interface, Spring will dynamically "generate" the implementation of data access methods. Extend the interface JpaRepository is optional, but the advantage is it already comes with several of generic CRUD methods and you don’t need to reset them all.

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

Creating new methods simply via signatures is very easy. See this example:

@Repository
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 prefix findBy in the names of the methods 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 by attribute nome using the value passed in the first parameter. In the second example, the generated query will use an expression with the operator AND considering the attributes cidade and estado.

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

See the documentation on cherishing for more details.

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

Example of JPA query:

public interface UserRepository extends JpaRepository<User, Long> {

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

}

Example of native query:

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

Customizing the Spring Data Jpa

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

Creating a specific implementation

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

1. Create an interface ClienteRepositoryCustom with the methods you want to implement.
2. Create a class in the same package ClienteRepositoryImpl implementing this interface.
3. Interface ClienteRepository extend the interface ClienteRepositoryCustom

See the documentation.

Creating a "generic interface"

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

Replacing the Jparepository implementation

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

I myself 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 whole process is outside the scope of the answer, as well as greatly lengthening the content. So I’m going to leave the link to one of the articles I used to make the implementation is Customizing Spring Data JPA Repository.

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

Answer 2

To DAO is a design pattern that abstracts the data persistence. A Repository is an abstraction of a collection of objects and their respective methods of handling. Both can exist in the same project. The crack DAO, Repository and DTO (Data Transfer Object) can be considered a Work Unit (Unit of Work).

A formal definition of DAO has on the Oracle website, in English: http://www.oracle.com/technetwork/java/dataaccessobject-138824.html. A translator can help.

A general overview of JPA repository can be found here: http://workingonbits.com/2011/05/05/effective-pattern-for-data-access-with-jpa/.

The JPA Repository is a special implementation of Repository, but note that the Repository is concerned with exposing methods that manipulate collections, not operations in databases such as DAO. In the case of the JPA Spring Repository, it proposes to do some things automatically (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). Correct, in the case of a fully integrated repository with a database, would be for the repository to update this transparently.