What’s the difference between DAO and Repository?

Question

What’s the difference between DAO and Repository?

Both are very similar, but in which case it is better to use one or the other?

I would like code examples.

Answer 1

The goal is the same: Serve as abstraction to persist the data.

There is only one difference in its mode of use:

A repository is bound by the application’s business rule and is associated with the aggregation of your business objects and returns domain objects that represent this data.

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

Repository: Appraisal is business rule, encompasses everything on that rule, returning business domain objects

class AvaliacaoRepository
{
     public List<Aluno> AlunosAvaliados();
     public List<Gerente> GerentesAvaliados();
     public List<Avaliacao> TodasAvaliacoes();
     public List<Avaliacao> AvaliacoesEmAguardo();
}

DAO: Evaluation / User are Tables and its functions return objects (DTO) that represent the database records.

class AvaliacaoDAO 
{
     public List<DTOAvaliacao> TodasAvaliacoes();
     public List<DTOAvaliacao> AvaliacoesEmAguardo();
}

class UsuarioDAO 
{
     public List<DTOUsuario> AlunosAvaliados();
     public List<DTOUsuario> GerentesAvaliados();
}

Answer 2

Warning: I decided to risk an answer because I found the other confused or abstract, giving room to different interpretations about the patterns.

TL;DR

DAO and Repository are two standards of important projects, whose purposes have a small intersection area. However, as we will see below, they differ both in their objects, as in their origin and implementation.

Daos deal directly with the data source and abstract the operations performed on it. Repositories provide an interface to treat the storage and retrieval of domain entities as a collection.

DAO

A Data Access Object (Data Access Object) is an object that provides an interface abstracting a database or some other external persistence mechanism from the application.

Objectives:

1. Encapsulation: Do not expose data source details to the rest of the application
2. One-time responsibility principle: being the only place that works with SQL or specific dialect of that data source
3. Meeting specific data source needs: properly mapping the application’s data structures or objects according to the specific data source types and structures

Example:

interface ClienteDao {
    void incluir(Cliente)
    void atualizar(Cliente)
    void atualizarUltimoAcesso(Integer,Date) //atualiza um campo
    Cliente recuperar(Integer)
    Cliente[] listarPorNome(String)
    ...
}

In summary, a DAO method follows the model:

umMetodoQualquerQueAbstraiUmaQueryEspecifica(ParametrosDaQuery)

Generally, each method of a DAO performs a single read or write operation in the database.

Repository

A Repository (Repository) is an object that isolates objects or entities of the domain of code that accesses the database.

We have that a repository implements part of the business rules regarding the composition of entities. It is strongly linked to the field of application and this is a direct reflection of the rules of business, because it abstracts storage and query of one or more domain entities.

However, we must not confuse this with business rules in the sense of information processing. A repository should not include business rules for making decisions, applying data transformation algorithms or providing services directly to other layers or modules of the application. Mapping domain entities and providing application functionality are separate responsibilities.

A repository is between the business rules and the persistence layer:

1. It provides an interface to the business rules where objects are accessed as in a collection.
2. It uses the persistence layer to record and recover the data needed to persist and recover the business objects.

So a repository can even make use of one or more Daos.

The interface of a repository is often analogous to the interface of List Java or C#, probably with the exception of search methods.

Example:

interface ClienteRepository {
    void persistir(Cliente)
    Cliente recuperar(Integer)
    List<Cliente> pesquisar(TermosDaPesquisa)
    List<Cliente> todos()
}

In the above example, in a simpler scenario, ClienteRepository.persistir() can make use of the method ClienteDao.incluir(). However, it can also check if the customer already exists and in this case use the method ClienteDao.atualizar(). Going further, if Cliente is a more complex domain entity it could load a list of addresses from another DAO.

Finally, repositories does not contain business rules, but contains logic to correctly build and persist the domain objects.

Frameworks ORM

Frameworks like Hibernate (Java) or Nhibernate (.NET) provide a much closer interface to the standard Repository because:

1. Work with collections. See methods persist() and find().
2. Searches are performed by an interface independent of the database type.
3. They carry out the work of building and storing the application entities, including the possibility to automatically recover relation values, as in the example above on the client address list.

In addition, they also play the role of DAO because:

• Store data directly in a database.
• Generate the necessary SQL queries.
• Map source data types to a suitable type in objects and vice versa.

On the other hand, it is clear that such frameworks can not always completely replace an application-specific repository because they are very generic. So even when using a ORM, it can be interesting not to mix your business rules with framework-specific code. In this case, creating Repositories that make use of the framework makes sense, as if it were a DAO++, after all you are at a higher level of abstraction and are not abstracting the access to the data source.

When to use the patterns

The use of Daos is practically a necessity if you do not use Orms, even if you use another nomenclature, after all you need a place to put SQL code.

Repositories, on the other hand, are interesting for slightly larger applications, where the cost of adding one more abstraction layer is justified by reuse in other components, modules and layers.

As described above, when working with an ORM, it makes sense to create repositories to abstract the framework-specific code. What doesn’t make much sense (I’ve seen it around) is to create Daos to abstract the ORM, because this is to force a little the concept of DAO.

Repositories are also quite useful for creating alternative implementations for storage. Because the interface is collections-based, it’s easy to implement a repository version using a list in memory, a very useful device for running unit tests or integration independently of the database.

Where they look like

The confusion starts because both DAO and Repository somehow abstract access to data, although, as we saw above, they have completely different levels of abstraction.

Another problem is that some of the operations (methods) of Daos and Repositories are common and, depending on the implementation, there is no difference. Part of this is the incorrect implementation of standards. Another part is because it is not always possible to follow the model in its completeness, for example when abstraction in the form of a collection penalizes performance in such a way that a repository needs to implement a lower-level method to make a functionality viable.

Where they diverge

A very important point to understand that the difference is not just accidental is to understand the origin of the patterns. While DAO was primarily designed to abstract generic data sources, the context in which Repository was designed involves DDD and can be used with other specific patterns. (source)

Daos can persist and recover Dtos or, in simpler systems, from the system’s own entities. Repositories always refer to an entity in the application domain. Of course you can extend the concept to other things, but it shouldn’t be the norm.

Daos usually abstract a query in the database. Repositories may need several queries to compose an entity.

Daos do not manage transactions. Repositories can manage or at least require execution within a transaction.

Daos directly access the data source. Repositories usually use some other mechanism to persist data, such as a ORM or Daos themselves.

Answer 3

I’m sorry, but the Repository should not be associated with any business rule. Both the DAO and the Repository should be "dumb".

A Repository is the class responsible for all access to data of an Entity, actions such as include, edit, delete, and several queries are in the repository.

Other classes in a layer above the repositories are responsible for the business rules and consume the repositories to access the data.

Typically when used with interfaces the use of repositories dramatically speeds up the creation of the data access layer.

Here’s a simple example in C#:

Taking into account that you have a class that inherits from DbContext calling for SuaClasseDbContext (simplifying) this way:

public class SuaClasseDbContext : DbContext
{
   public DbSet<Autor> Autores {get; set;}
}

This interface says all entities must have a Id, which would be the primary key:

public class IEntidade
{
   public long Id; 
}

A generic repository, where the interface of a repository accepts any class that implements the interface IEntidade is defined with the basic methods:

public interface IRepositorio<T> where T: IEntidade
{
     void Adicionar(T entity);
     void Apagar(T entity);
     void Atualizar(T entity);
     void Salvar();
     T ObterPorId(int Id);
     IEnumerable<T> ObterTodos();
     IEnumerable<T> ObterPorFiltro(Expression<Func<T, bool>> filtro);
}

Next a class that represents an entity in your system, see that it implements the interface IEntidade:

public class Autor : IEntidade
{
    public int Id { get; set; }
    public string Nome { get; set; }
}

Then we can create the repository by implementing the defined interface:

public class AutorRepositorio : IRepositorio<Autor>
{
    private readonly SuaClasseDbContext dbContext;

    public AutorRepositorio(SuaClasseDbContext dbContext)
    {
        this.dbContext = dbContext;
    }
    
    public void Adicionar(Autor autor)
    {
        SuaClasseDbContext.Autores.Add(autor);
    }
    
    public void Apagar(Autor autor)
    {
        SuaClasseDbContext.Autores.Remove(autor);
    }
    
    public void Atualizar(Autor autor)
    {
            SuaClasseDbContext.Entry(autor).State = System.Data.Entity.EntityState.Modified;
    }

    public void Salvar()
    {
        SuaClasseDbContext.SaveChanges();
    }
    
    public Autor ObterPorId(int Id)
    {
        return SuaClasseDbContext.Autores.Find(Id);
    }
    
    public IEnumerable<Autor> ObterTodos()
    {
        return SuaClasseDbContext.Autores.ToList();
    }
    
    public IEnumerable<Autor> ObterPorFiltro(Expression<Func<Autor, bool>> filtro)
    {
        return SuaClasseDbContext.Autores.Where(filtro).ToList();
    }
}

When it’s time to use a Console Application, for example:

IRepositorio<Autor> repositorio = new AutorRepositorio();

// Regra de negócio responsável por consultar todos os autores que comecem
// com a letra A
// a regra de negócio está no consumo do repositório e não dentro dele
var resultado = repositorio.ObterPorFiltro(a => a.Nome.StartsWith("A"));
            
foreach (var autor in resultado)
{
   Console.WriteLine(autor.Nome);
 
}

Answer 4

Queries sql, jpaql, hql or whatever, are related yes to business rule, not directly and yes indirectly. So you can extract exactly the information you need from any repositório de dados, you need a pattern for this extraction to be done, in sgbds we use consultations sql.

Data access Objects are objects intended to abstract the way the information necessary for the execution of business rules is accessed, either through a sgbd, ldap, arquivo, filesystem etc. if we add query rules to these objects we will plaster them to just scan data that will obey that rule.

Repositories are responsible for manipulating this information already mined/extracted, either using the related languages above or another technique for the same purpose, it is clear that we will not have explicit business rules in these objects due to a better maintenance and or evolution (even if the implementation of the rule is query) for this reason our business objects will make use of these "data repositories" so that they can execute these rules.

A clear and practical example of this is the use of a relational object mapping that to facilitate the understanding we talk about the jpa/hibernate, where the classes responsible for containing the consultations jpaql/hql are not DAOS (taking into account the above definition), much less business objects but has the responsibility to contain the data we need to apply one or more rules.