DAO ou Repository? Qual usar?
14/06/2017
0
Olá, pessoal. Tudo bem com vocês?
Em meus estudos sobre padrões de projeto vi muito ser usado o DAO (Data Access Objects). Porém, mais recentemente vi também o padrão Repository, que faz quase a mesma coisa. Então me surgiu a dúvida de quando usar um ou outro. Qual é a diferença entre eles?
Obg. =)
Em meus estudos sobre padrões de projeto vi muito ser usado o DAO (Data Access Objects). Porém, mais recentemente vi também o padrão Repository, que faz quase a mesma coisa. Então me surgiu a dúvida de quando usar um ou outro. Qual é a diferença entre eles?
Obg. =)
Rachel Andrade
Curtir tópico
+ 2
Responder
Post mais votado
17/06/2017
Olá Rachael.
O DAO e o Repository podem ser usados juntos, mas são padrões com funções diferentes.
O DAO é considerado um padrão de integração e é usado como parte da infraestrutura da aplicação. Um DAO serve para você especificar qual o banco de dados vai ser usado, como ele será usado e todas as instruções que devem ser passadas a ele. Ou seja, o DAO conhece e sabe exatamente com qual infraestrutura (banco de dados, arquivos, memória, ...) ele está lidando.
O Repository é considerado um padrão de domínio e faz parte das regras de negócios de uma aplicação. Esse padrão não tem conhecimento da infraestrutura, assim, ele não sabe que está lidando com um banco de dados. Sua real função é trabalhar como uma porta ou janela de acesso a outra camada, que poderia ser o DAO.
E o que ele faz? Apenas retorna um objeto de domínio, como um objeto Pessoa ou uma lista de objetos do tipo Pessoa. Como ele retorna isso, bem, isso é um segredo para ele, já que ele não sabe o que está acontecendo do outro lado da janela.
Antes do uso de frameworks ORM, como o Hibernate, o DAO era bastante usado em aplicações com acesso a banco de dados. Com a chegada dos frameworks ORM ele continuou sendo usado, mas na verdade os frameworks é que fazem o trabalho de DAO, porque são eles que conhecem e lidam com a infraestrutura.
Só que se continuou usando o nome DAO para adicionar as classes que continham as instruções de CRUD. Algo como um extensão do que os frameworks ofereciam. Essa pratica gerou algumas controvérsias.
Alguns assumem que sim, se pode chamar essas classes de DAO, porque se elas possuem os objetos de consulta a banco de dados e as instruções HQL, JPQL ou mesmo SQL, seria ainda infraestrutura. Porque são comandos específicos de banco de dados e banco de dados estão ligados a infraestrutura.
Outros defendem que essas classes, com as consultas e demais operações, seriam um repositório. Já que quem lida com a infraestrutura é o framework.
Mas, o repositório deveria ser apenas uma janela, não deveria saber que um HQL vai devolver um objeto Pessoa ou uma lista qualquer de pessoas. Por conta disso, não se chega realmente a uma conclusão.
Eu acho que as classes com as instruções de banco de dados, mesmo usando um framework, são um DAO e a forma como você vai invocar os métodos dessas classes, poderia então ser o Repositoty.
Um exemplo bastante comum de DAO é aquele onde para cada classe concreta você tem uma interface:
Eu considero essa interface como o Repositório. Desde que você acesse os métodos através da interface e não da classe concreta:
Porque eu considero a interface o repositório? Porque se eu trocar o meu banco de dados relacional por um não relacional, a interface não vai saber disso, mas terei que de alguma forma mudar a implementação dos métodos da classe PessoaDao. As vezes, dependendo do banco de dados relacional, a própria instrução de consulta sofre diferenças devido ao dialeto especifico de cado banco de dados (Oracle, DBII, MySQL, PostgreSQL, H2, ...)
Outra coisa, se eu resolver não usar mais um banco de dados e sim arquivos, preciso mudar o DAO, mas a interface ainda continuaria intacta, sem saber que eu mudei a infraestrutura.
Desculpa pela longa resposta, mas é difícil falar sobre isso com poucas linhas. Agora, talvez você possa criar sua própria opinião sobre esses padrões.
O DAO e o Repository podem ser usados juntos, mas são padrões com funções diferentes.
O DAO é considerado um padrão de integração e é usado como parte da infraestrutura da aplicação. Um DAO serve para você especificar qual o banco de dados vai ser usado, como ele será usado e todas as instruções que devem ser passadas a ele. Ou seja, o DAO conhece e sabe exatamente com qual infraestrutura (banco de dados, arquivos, memória, ...) ele está lidando.
O Repository é considerado um padrão de domínio e faz parte das regras de negócios de uma aplicação. Esse padrão não tem conhecimento da infraestrutura, assim, ele não sabe que está lidando com um banco de dados. Sua real função é trabalhar como uma porta ou janela de acesso a outra camada, que poderia ser o DAO.
E o que ele faz? Apenas retorna um objeto de domínio, como um objeto Pessoa ou uma lista de objetos do tipo Pessoa. Como ele retorna isso, bem, isso é um segredo para ele, já que ele não sabe o que está acontecendo do outro lado da janela.
Antes do uso de frameworks ORM, como o Hibernate, o DAO era bastante usado em aplicações com acesso a banco de dados. Com a chegada dos frameworks ORM ele continuou sendo usado, mas na verdade os frameworks é que fazem o trabalho de DAO, porque são eles que conhecem e lidam com a infraestrutura.
Só que se continuou usando o nome DAO para adicionar as classes que continham as instruções de CRUD. Algo como um extensão do que os frameworks ofereciam. Essa pratica gerou algumas controvérsias.
Alguns assumem que sim, se pode chamar essas classes de DAO, porque se elas possuem os objetos de consulta a banco de dados e as instruções HQL, JPQL ou mesmo SQL, seria ainda infraestrutura. Porque são comandos específicos de banco de dados e banco de dados estão ligados a infraestrutura.
Outros defendem que essas classes, com as consultas e demais operações, seriam um repositório. Já que quem lida com a infraestrutura é o framework.
Mas, o repositório deveria ser apenas uma janela, não deveria saber que um HQL vai devolver um objeto Pessoa ou uma lista qualquer de pessoas. Por conta disso, não se chega realmente a uma conclusão.
Eu acho que as classes com as instruções de banco de dados, mesmo usando um framework, são um DAO e a forma como você vai invocar os métodos dessas classes, poderia então ser o Repositoty.
Um exemplo bastante comum de DAO é aquele onde para cada classe concreta você tem uma interface:
interface PessoaDao {
//assinaturas
}
class PessoaDaoImpl implements PessoaDao {
//métodos
}
Eu considero essa interface como o Repositório. Desde que você acesse os métodos através da interface e não da classe concreta:
interface PessoaRepository {
//assinaturas
}
class PessoaDaoImpl implements PessoaRepository {
//métodos
}
Porque eu considero a interface o repositório? Porque se eu trocar o meu banco de dados relacional por um não relacional, a interface não vai saber disso, mas terei que de alguma forma mudar a implementação dos métodos da classe PessoaDao. As vezes, dependendo do banco de dados relacional, a própria instrução de consulta sofre diferenças devido ao dialeto especifico de cado banco de dados (Oracle, DBII, MySQL, PostgreSQL, H2, ...)
Outra coisa, se eu resolver não usar mais um banco de dados e sim arquivos, preciso mudar o DAO, mas a interface ainda continuaria intacta, sem saber que eu mudei a infraestrutura.
Desculpa pela longa resposta, mas é difícil falar sobre isso com poucas linhas. Agora, talvez você possa criar sua própria opinião sobre esses padrões.
Marcio Souza
Responder
Mais Posts
19/06/2017
Wesley Yamazack
Excelente explicação, Ballem! Muito obrigado por compartilhar conosco todo esse conhecimento. :)
[]'
[]'
Responder
21/06/2017
Gladstone Matos
bom dia Marcio excelente explicacao muito obrigado pelo compartilhamento de conhecimento ;-)
abracos
abracos
Responder
11/06/2023
Dacio Braga
Boa explicação, porém senti falta de exemplos em aplicação real, onde mostra até onde vai um padrão e começa o outro. Se é que isso possa existir.
Responder
07/12/2023
Leticia Lima
O padrão de projeto DAO (Data Access Object) e o padrão Repository têm semelhanças, pois ambos são projetados para lidar com a camada de persistência e abstrair o acesso aos dados, mas há algumas diferenças conceituais e de implementação entre eles.
DAO (Data Access Object):
Objetivo:
O DAO é focado na abstração da lógica de acesso a dados para um determinado tipo de entidade (classe).
Ele fornece uma interface para operações básicas de CRUD (Create, Read, Update, Delete) para uma única entidade.
Responsabilidades:
Encapsula o acesso a um único tipo de entidade.
Geralmente, um DAO é específico para uma entidade e contém métodos para realizar operações no banco de dados relacionadas a essa entidade.
Exemplo:
Se você tiver uma classe Usuario, seu DAO correspondente terá métodos como saveUsuario, getUsuarioById, updateUsuario, etc.
Repository:
Objetivo:
O Repository é focado em fornecer uma interface para acesso a coleções de objetos (entidades).
Ele abstrai o acesso a múltiplos tipos de entidades e fornece métodos para recuperar conjuntos de dados específicos.
Responsabilidades:
Encapsula a lógica de consulta para várias entidades.
Pode conter métodos para recuperar conjuntos específicos de entidades com base em critérios de consulta.
Exemplo:
Se você tiver classes Usuario e Produto, seu Repository poderia ter métodos como getUsuariosByCriteria ou getProdutosByCategoria.
DAO (Data Access Object):
Objetivo:
O DAO é focado na abstração da lógica de acesso a dados para um determinado tipo de entidade (classe).
Ele fornece uma interface para operações básicas de CRUD (Create, Read, Update, Delete) para uma única entidade.
Responsabilidades:
Encapsula o acesso a um único tipo de entidade.
Geralmente, um DAO é específico para uma entidade e contém métodos para realizar operações no banco de dados relacionadas a essa entidade.
Exemplo:
Se você tiver uma classe Usuario, seu DAO correspondente terá métodos como saveUsuario, getUsuarioById, updateUsuario, etc.
Repository:
Objetivo:
O Repository é focado em fornecer uma interface para acesso a coleções de objetos (entidades).
Ele abstrai o acesso a múltiplos tipos de entidades e fornece métodos para recuperar conjuntos de dados específicos.
Responsabilidades:
Encapsula a lógica de consulta para várias entidades.
Pode conter métodos para recuperar conjuntos específicos de entidades com base em critérios de consulta.
Exemplo:
Se você tiver classes Usuario e Produto, seu Repository poderia ter métodos como getUsuariosByCriteria ou getProdutosByCategoria.
Responder
Clique aqui para fazer login e interagir na Comunidade :)