Qual é a diferença entre os padrões DAO e Repositório?

Qual é a diferença entre o Data Access Objects (DAO) e os padrões do Repository? Estou desenvolvendo um aplicativo usando o Enterprise Java Beans (EJB3), o Hibernate ORM como infra-estrutura e o Domain-Driven Design (DDD) e o Test-Driven Development (TDD) como técnicas de design.

DAO é uma abstração de persistência de dados. Repositório é uma abstração de uma coleção de objects.

O DAO seria considerado mais próximo do database, geralmente centrado em tabelas. Repositório seria considerado mais próximo do Domínio, lidando apenas com Raízes Agregadas. Um Repositório poderia ser implementado usando o DAO, mas você não faria o oposto.

Além disso, um Repositório é geralmente uma interface mais estreita. Deve ser simplesmente uma coleção de objects, com Get(id) , Find(ISpecification) , Add(Entity) . Um método como Update é apropriado em um DAO, mas não em um Repository – ao usar um Repository, as alterações em entidades geralmente seriam rastreadas por UnitOfWork separado.

Parece comum ver implementações chamadas Repository que são realmente mais um DAO e, portanto, acho que há alguma confusão sobre a diferença entre elas.

OK, acho que posso explicar melhor o que eu coloquei nos comentários :). Então, basicamente, você pode ver ambos como o mesmo, embora o DAO seja um padrão mais flexível que o Repositório. Se você quiser usar ambos, você usaria o Repositório em seus DAO-s. Vou explicar cada um deles abaixo:

REPOSITÓRIO:

É um repository de um tipo específico de objects – ele permite que você procure por um tipo específico de objects, além de armazená-los. Normalmente, ele só irá lidar com um tipo de objects. Por exemplo, o AppleRepository permitiria que você fizesse AppleRepository.findAll(criteria) ou AppleRepository.save(juicyApple) . Observe que o Repositório está usando termos do Modelo de Domínio (não termos do BD – nada relacionado a como os dados são persistidos em qualquer lugar).

Um repository provavelmente armazenará todos os dados na mesma tabela, enquanto o padrão não exige isso. O fato de ele manipular apenas um tipo de dado, torna-o logicamente conectado a uma tabela principal (se usada para persistência de database).

DAO – object de access a dados (em outras palavras – object usado para acessar dados)

Um DAO é uma class que localiza dados para você (é principalmente um localizador, mas é comumente usado para também armazenar os dados). O padrão não restringe você a armazenar dados do mesmo tipo, portanto, você pode facilmente ter um DAO que localize / armazene objects relacionados.

Por exemplo, você pode facilmente ter UserDao que expõe methods como

 Collection findPermissionsForUser(String userId) User findUser(String userId) Collection findUsersForPermission(Permission permission) 

Todos aqueles estão relacionados ao usuário (e segurança) e podem ser especificados sob o mesmo DAO. Este não é o caso do Repositório.

Finalmente

Note que ambos os padrões realmente significam o mesmo (eles armazenam dados e eles abstraem o access a ele e ambos são expressos mais perto do modelo de domínio e dificilmente contêm qualquer referência DB), mas a maneira como eles são usados ​​pode ser ligeiramente diferente, sendo DAO um pouco mais flexível / genérico, enquanto Repository é um pouco mais específico e restritivo para um tipo apenas.

Os padrões DAO e Repository são formas de implementar a camada de access a dados (DAL). Então, vamos começar com o DAL primeiro.

Aplicativos orientados a objects que acessam um database, devem ter alguma lógica para manipular o access ao database. Para manter o código limpo e modular, é recomendável que a lógica de access ao database seja isolada em um módulo separado. Na arquitetura em camadas, este módulo é o DAL.

Até agora, não falamos sobre nenhuma implementação em particular: apenas um princípio geral que coloca a lógica de access ao database em um módulo separado.

Agora, como podemos implementar esse princípio? Bem, uma maneira conhecida de implementar isso, em particular com frameworks como o Hibernate, é o padrão DAO.

O padrão DAO é uma maneira de gerar o DAL, onde normalmente cada entidade de domínio tem seu próprio DAO. Por exemplo, User e UserDao , Appointment and AppointmentDao , etc. Um exemplo de DAO com Hibernate: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .

Então o que é padrão Repositório? Como o DAO, o padrão Repositório também é uma maneira de atingir o DAL. O ponto principal no padrão Repositório é que, da perspectiva do cliente / usuário, ele deve se parecer ou se comportar como uma coleção. O que se entende por se comportar como uma coleção não é que ela Collection collection = new SomeCollection() ser instanciada como Collection collection = new SomeCollection() . Em vez disso, significa que ele deve suportar operações como adicionar, remover, conter, etc. Essa é a essência do padrão Repositório.

Na prática, por exemplo, no caso de usar o Hibernate, o padrão de Repositório é realizado com o DAO. Essa é uma instância de DAL pode ser tanto a mesma instância de padrão DAO e padrão de repository.

Padrão de repository não é necessariamente algo que se constrói em cima do DAO (como alguns podem sugerir). Se os DAOs forem projetados com uma interface que suporte as operações mencionadas acima, ela será uma instância do padrão Repositório. Pense nisso: se os DAOs já fornecem um conjunto de operações semelhantes a uma coleção, qual é a necessidade de uma camada extra sobre ela?

Francamente, isso parece uma distinção semântica, não uma distinção técnica. A frase Data Access Object não se refere a um “database”. E, embora você possa projetá-lo para ser centrado no database, acho que a maioria das pessoas consideraria fazer uma falha de design.

O objective do DAO é ocultar os detalhes de implementação do mecanismo de access a dados. Como o padrão do repository é diferente? Tanto quanto eu posso dizer, não é. Dizer que um Repositório é diferente de um DAO porque você está lidando com / return uma coleção de objects não pode estar certo; Os DAOs também podem retornar collections de objects.

Tudo o que li sobre o padrão do repository parece depender desta distinção: design DAO ruim versus design DAO bom (também conhecido como padrão de design do repository).

Repositório é um termo orientado ao domínio mais abstrato que faz parte do Design Dirigido por Domínio, faz parte do design do seu domínio e uma linguagem comum, DAO é uma abstração técnica para a tecnologia de access a dados, repository só se preocupa em gerenciar dados e fábricas existentes para criação de dados.

verifique estes links:

http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html

A principal diferença é que um repository manipula o access às raízes agregadas em um agregado, enquanto o DAO manipula o access a entidades. Portanto, é comum que um repository delega a persistência real das raízes agregadas a um DAO. Além disso, como a raiz agregada deve manipular o access das outras entidades, talvez seja necessário delegar esse access a outros DAOs.

Repositório não são nada além de DAO bem desenhado.

ORM são centrados em tabela, mas não em DAO.

Não há necessidade de usar vários DAO no repository, pois o próprio DAO pode fazer exatamente o mesmo com repositorys ORM / entidades ou qualquer provedor DAL, não importa onde e como um carro é mantido 1 tabela, 2 tabelas, n tabelas, meia mesa, um serviço da Web, uma tabela e um serviço da Web, etc. Os serviços usam vários DAO / repositorys.

Meu próprio DAO, digamos que CarDao só lida com o DTO de carro, quero dizer, só leve DTO de carro em input e só devolva DTO de carro ou collections de DTO de carro em saída.

Então, assim como o Repositório, o DAO é realmente uma IoC, para a lógica de negócios, permitindo que interfaces de persistência não sejam intimidadas por estratégias ou legados de perseverança. O DAO encapsula a estratégia de persistência e fornece a interface de persistência relacionada ao domaine. Repositório é apenas uma outra palavra para aqueles que não entenderam o que realmente era um DAO bem definido.

Tente descobrir se o DAO ou o padrão Repositório é mais aplicável à seguinte situação: Imagine que você gostaria de fornecer uma API de access a dados uniforme para um mecanismo persistente para vários tipos de fonts de dados, como repositorys RDBMS, LDAP, OODB, XML e arquivos simples.

Consulte também os links a seguir, se estiver interessado:

http://www.codeinsanity.com/2008/08/repository-pattern.html

http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/

http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx

http://en.wikipedia.org/wiki/Domain-driven_design

http://msdn.microsoft.com/pt-br/magazine/dd419654.aspx