Olá
Tenho lido muitos tópicos no guj sobre esses assuntos nos últimos dias, mas uma dúvida que pairou foi a seguinte:
Qual a diferença entre um Repository e um DAO?
Sei que o DAO é responsável pela abstração do mecanismo de persistência, e que regras de negócio não devem estar contidas nele (por favor, corrijam-me se eu estiver errado).
Nesse caso, as regras ficam dentro do Repository?
Estou bastante confuso. Se puderem, por favor indiquem-me alguns artigos ou livros.
Abraços
[quote=tnaires]Olá
Tenho lido muitos tópicos no guj sobre esses assuntos nos últimos dias, mas uma dúvida que pairou foi a seguinte:
Qual a diferença entre um Repository e um DAO?
Sei que o DAO é responsável pela abstração do mecanismo de persistência, e que regras de negócio não devem estar contidas nele (por favor, corrijam-me se eu estiver errado).
Nesse caso, as regras ficam dentro do Repository?
[/quote]
Sim é isso mesmo.
Basta fazer uma busca aqui no guj ou no google.
Na realidade fica onde vc quiser, uma vez que vc está programando! 
Considera-se uma boa prática colocar as regras de negócio nas classes de negócio, também conhecidas como model ou modelo.
Repositorios são utilizados como centros de acesso às entidades do seu sistema (que não necessariamente são entidades de banco de dados). Já os DAOs são a camada de acesso às suas entidades de banco de dados.
Com isso vc tem a ligação entre Repositorios e DAOs.
É uma boa prática, criando um modelo de dominio, colocar as regras de negocio em outra classe que não seja o DAO. Isso pode ficar no repositorio (se vc utiliza-lo como classe) ou em um BusinessObject/Service/Manager e outras nomeclaturas existentes no mercado.
Lembre-se: a melhor arquitetura é a a que resolve seu problema de uma maneira mais facil e mais difundida na sua equipe de desenvolvimento. Não adianta vc colocar os 24 padrões exigidos em uma certificação de arquiteto sem que sua equipe saiba trabalhar com os mesmos!
Obrigado a todos pelas respostas.
Rodrigo, suponha que tenho uma aplicação que guarde os objetos apenas em memória, sem nenhuma forma de persistência (ou seja, quando o aplicativo finalizar, tudo será perdido). Nesse caso, os DAOs não são mais necessários, apesar de os repositórios ainda o serem. Isso está correto?
Lendo as várias discussões presentes no GUJ, tive acesso a links interessantíssimos, tais quais o texto do Phillip Calçado sobre BOs e VOs e o resumo de Domain-Driven Design (que por sinal ainda não terminei de ler), e pude inferir que manter a lógica de negócio em BOs, na verdade, pode não ser uma boa prática, uma vez que separa-se dados de comportamento. É isso mesmo ou a coisa não é bem por aí?
Outra dúvida: como assim utilizar o repositório como classe? O repositório seria uma interface? Se sim, suponho que a sua implementação seja o DAO… Mas aí, em tese, não poderei alocar a lógica de negócio no meu repositório. Da forma como eu estava pensando, eu teria algo do tipo:
[code]public interface Repository {
public List obterDadosDeAcordoComAlgumaRegraDeNegocio()
}
public class EntidadeRepository implements Repository {
EntidadeDAO dao;
public EntidadeRepository() {
dao = new EntidadeDAO();
}
public List<Entidade> obterDadosDeAcordoComAlgumaRegraDeNegocio() {
List<Entidade> result = dao.getAll();
// Aplicar a lógica de negócio aqui, de acordo com a entidade em questão
return result;
}[/code]
Como podem notar, estou bastante confuso com relação a alguns conceitos… Agradeço os esclarecimentos.
Abraços