Can I use the DAO and Repository project patterns together?

Navigation
5

I'm studying data persistence in Java and these two patterns came to me: DAO and Repository. Many say that it is better to use DAO, while others prefer the Repository. Already some mention the use of both in the project.
So I thought about using DAO in the underlying layer, with direct access to the database and the repositories in the business layer using DAO's and applying the business rules. I would like to hear from you regarding this practice and suggestions for good practice with persistence of data.

    
asked by anonymous 18.04.2015 / 05:28

1 answer

3

That's an interesting question and I think it's recurring on Stack. I will use as a java language that I have more mastery, but this rule applies to any language, since we are talking about Software Design.

DAO

As a near answer, you can rely on this other answer:

What's the difference between DAO and Repository?

  

A repository is linked to the business rule of the application and is   associated with the aggregate of your business objects and returns   which these data represent.

     

...

     

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

What I do not think was very consistent, was the practical explanation of it. The perfect world of DAO should be just the basic operations we need to handle the data (regardless of whether the vendor is a relational database, file, or anything else that can hold a state):

  • retrieveIdentifier
  • 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 Searchfilter (which is a parameter, commonly known as "Query Object")

Repository

This, properly represents the data that the business needs to obtain. We will request them for DAO.

Usually has the same basic DAO methods (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 >):

  • retrieveIdentifier
  • add
  • remove
  • upgrade
  • list
  • list with a SearchFilter

and the methods your business often needs to get filtered data:

  • list ActiveUsers 
UsuarioFilter usuarioFilter = new UsuarioFilter();
usuarioFilter.setAtivo(true);

List<Usuario> usuariosAtivos = usuarioDAO.listar(usuarioFilter);
  • getUltimateUsername 
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 to.

Important references

20.04.2015 / 23:49
Is it possible to implement null or undefined methods? Check if Input :: file exists Laravel