Legal o post, mais legal ainda a coincidência Hahaha

[ ]s, gc

http://sergiotaborda.wordpress.com/2008/06/16/sindrome-de-dao/

Vou tentar fazer um post esclarecendo esse assunto. Enquanto isso dá uma lida aqui: http://nullability.org/?p=97

Eu acho que sou mais um dos que não entenderam a diferença prática entre um Repositório vs. DAO. Eu entendi a sua explicação qdo diz q o Reposítório faz parte do modelo de domínio, enquanto um DAO faz parte da infra-estrutura da aplicação.

Entretanto, um DAO ja é uma abstração do mecanismo de persistência. Os exemplos de código que andei vendo as pessoas “aplicando” esse conceito de repositório foi criando exatamente essa camada adicional para abstrair o próprio DAO. Ou seja, uma abstração da abstração.

Não consegui ver qual o real ganho dessa camada se a única coisa que esta sendo feito é criado mais um nível de indireção sem nenhum ganho concreto.

Enfim, se tiver algum trecho de código para postar demonstrando esses conceitos e diferenças, talvez fique mais fácil para mim e para outras pessoas que ainda não conseguiram visualizar bem a vantagem e a aplicação desse conceito.

De qualquer forma, parabens pelo o trabalho. O blog é excelente.

Abraço,
Eduardo Amuri

Muito bom seu post fazendo essa distinção de DAO sendo objetos de infra-estrutura e Repository sendo objetos do domínio.

Erros como este que você citou, de renomear os DAO’s, são muito comuns, pois mesmo o Livro do Eric Evans não explica a diferença de DAO x Repositóry na prática, no código. Então fica a sugestão caso queira publicar um trecho de código ou uma modelagem, para que a gente possa entender melhor essa diferença na prática!

[]’s

Eu li o Applying DDD do Jimmy Nilsson mas achei meio confuso; parece um blog post de 500 páginas. Eu aproveitei bem mais o novo do Dino Esposito (http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-PRO-Developer/dp/073562609X?tag=iheartworld-20). Outra referência legal (e gratuita) é o DDD Quickly (http://www.infoq.com/minibooks/domain-driven-design-quickly)

Sobre DAO x Repository, eu gosto de pensar em repositórios como uma forma de oferecer uma API limpa e homogênea para as camadas de cima. Mas também acho que em muitos casos pode ser exagero, aplicações simples não teriam problema nenhum em usar os bons e velhos active records e coisas do genêro. Vejo muita gente em blogs e lá no stackoverflow.com recomendando que se use repositórios em aplicação com 3 classes e 3 tabelas, meio demais né.

Abraço

Repository é isso que você leu no post, um padrão de Domain-Driven Design que esabelece um componente dentro do modelo de domínio para trabalhar com persistência de dados.

Já o Business Object é um padrão J2EE que teoricamente serve para “evitar duplicação de regras de negócios”. Os BOs são objetos que no fundo só servem para passar objetos anêmicos de um lado pro outro (os Transfer Objects). Essa abordagem está cada vez mais em desuso e não faz sentido em DDD. Mais detalhes aqui: http://www.corej2eepatterns.com/Patterns2ndEd/BusinessObject.htm

[ ]s, gc

Eu nunca lí não mas já me falaram que o livro Applying Domain-Driven Design (http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202/ref=sr_1_1?ie=UTF8&s=books&qid=1232406832&sr=1-1) tem bastante exemplos. Os códigos são em C#, mas quem entende Java não deve ter problemas para entender.

[ ]s, gc