[quote=Daniel_MV][quote=marvinla][quote=Daniel_MV]
Ou seja, abusando da abstração, poderia enxergar o repositório como uma “facade” para um DAO ou outras implementações de consultas a arquivos, banco de dados, WS, etc…?[/quote]
No livro de DDD do Eric Evans (o livro azul) ele diz para enxergarmos os reposiórios como Coleções com métodos epecializados para seu negócio, exemplos:
adicionar
retornarTodosOsQuartos()
retornarQuartosDisponiveis()
etc.[/quote]
Então considerando que exista um DAO que já utiliza esse tipo de nomenclatura em vez de termos técnicos (como eu costumo fazer normalmente).
DAOHotel{
void adicionarReserva(Cliente c);
List<Quartos> retornarTodosOsQuartos();
List<Quartos> retornarQuartosDisponiveis();
}
Qual seria a grande vantagem? A não ser isolar negócio da implementação da consulta. Mas isso um Negocio já faz.
[code]NegocioHotel{
List retornarTodosOsQuartos(){
/// Consulta mais regras de negócio.
return new DAOHotel().retornarTodosOsQuartos();
}
}[/code]
Ao meu ver o benefício que vejo dos repositórios nesse caso (lembrando que ainda estou tentando entender o DDD) seria essa “facade”, tendo uma camada a mais para abstração.
Seria isso?
[/quote]
Os repositórios podem acessar DAOs convencionais, acessando um banco de dados, pode encapsular o acesso a um WEB Service, um XML, etc. Como disse, como se fosse uma coleção de objetos de um tipo, não importando de onde vem o resultado.
Além disso, para entender melhor o uso de repositórios, é importante também o conceito de Aggregates e Aggregate Roots[1]. Em DDD você tem um repositório para cada Aggregate Root. Este repositório (como unico componente da camada de negocios a enxergar a infra-estrutura) pode conter N DAOs. Os DAOs você tem em uma base de 1 DAO por classe a ser persistida(não necessáriamente…).
Fugindo um pouco do setor de hotelaria, que não conheço, um exemplo mais tradicional:
Classes Pedido e ItemPedido (clássico). O Pedido é seu Aggregate Root (a raiz do Aggregate). Você teria um RepositorioPedido. Porém, poderia ter um DAOPedido e DAOItemPedido, cada um responsável por persistir suas respectivas classes.
[1] http://en.wikipedia.org/wiki/Domain-driven_design#Building_Blocks_of_DDD