Can I use the DAO and Repository project standards together?

Question

I’m studying data persistence in Java and I came up with these two standards: DAO and Repository.
Many say that it is better to use DAO, while others say that Repository is better. Already some cite the use of both in the project.
So I thought of using the DAO in the infra layer, with direct access to the bank and the repositories in the business layer using the DAO’s and applying the business rules.
I would like to know your opinion about this practice and best practice suggestions with data persistence.

Answer 1

That’s an interesting question and I think it recurs in Stack. I will use as java language I have more domain, but this rule applies to any language since we are talking about Software Design.

DAO

As almost answer, you can base yourself on this other answer:

What is the difference between DAO and Repository?

A repository is bound by the application’s business rule and is associated with the aggregation of your business objects and returns objects from domain representing such data.

...

The DAO (Data Access Object) at first has its limited scope on capture and persistence of data from an DTO (Data Transfer Object) representing a database record, consequently it transmits only the relational physical world of the database and not represents the real business mini-world of your application.

What I don’t think was very coherent was her practical explanation. The perfect world of DAO should be exactly the basic operations we need to handle the data (regardless of whether the vendor is a relational database, archive or anything else that can maintain a state):

• recover
• add
• remove
• upgrade
• list (some people find this method unnecessary as it would be the same as a search without a search filter)
• list with a fileDPquery(which is a parameter, usually known as "Query Object")

Repository

This is the data that the business needs to obtain. We will request them to the DAO.

It usually has the same basic DAO methods (it is not a rule, you could limit the view in your software only to those methods that are called directly by the business layer, which is usually named with Service):

• recover
• add
• remove
• upgrade
• list
• list with a child

and the methods your business usually needs to obtain filtered data:

• list of your roomsTools

UsuarioFilter usuarioFilter = new UsuarioFilter();
usuarioFilter.setAtivo(true);

List<Usuario> usuariosAtivos = usuarioDAO.listar(usuarioFilter); 

• get winUltiumRoomsCasted

UsuarioFilter usuarioFilter = new UsuarioFilter();
usuarioFilter.getOrdersBy().add(UsuarioFilter.OrderBy.DATA_CADASTRO_DESC);
usuarioFilter.setLimit(1);

List<Usuario> usuarios = usuarioDAO.listar(usuarioFilter);
Usuario ultimoUsuarioCadastrado = usuarios.isEmpty() ? null : usuarios.iterator().next(); // ou usuarios.get(0);

The recommended scenario is Service -> Repository -> DAO

Here is a link to a more detailed explanation if you need.

Important references

• Identify Field
• Repository