Caso eu resolvesse usar o repository (Isso é so suposição para meu entendimento, não faz parte do meu trabalho não, nem sou arquiteto), eu teria então VIEW --> BUSINESS--> REPOSITORY --> DAO.

O repositóry não criaria um passo redundante, levando em conta que ja tenho uma camada tratando negócio ? Posso crer que o repository dispensa outras camadas de negócio ? Ou ele seria complemento ao negócio ?

Acredito que não ficaria redundante... estive lendo sobre o assunto recentemente e entendi que deveriam existir ambos Repository e DAO, já que o Repository não deveria se envolver em questões de infra estrutura...

FernandoFranzini wrote:

Acredito que não ficaria redundante... estive lendo sobre o assunto recentemente e entendi que deveriam existir ambos Repository e DAO, já que o Repository não deveria se envolver em questões de infra estrutura...

A questão é q não envolve....
1) Faz 1 interface RepositoryCliente com as operações.
2) Gere filosofias diferentes de respositorios polimorficamente..tipo:
- RepositoryClienteOracleImp
- RepositoryClienteMySqlImp
- RepositoryClienteWebServiceImp
- RepositoryClienteLDAPImp
- Etc....
Não existe necessidade de colocar outra abstração de DAO dentro...é so deixar o polimorfismo fazer o trabalho dele...

Se a abstração do Repository é a mesma do DAO, qual a diferença em usar um ou outro modelo?

j0nny wrote:A forma como eu uso o Repository é a seguinte, exemplo de Cliente:

public interface ClienteRepository { //todos os métodos aqui } public class ClienteDao implements ClienteRepository { //os métodos sobrescritos aqui }

O DAO que fará a conexão com o banco, porém nas minhas lógicas vou trabalhar apenas com o Repository.

rogeriosantos77 wrote:Justificara então eu usar o respository junto com DAO´s para encapular a implementação da infra propriamente dita, então :
Por exemplo, dentro do meu ClienteRepository haveriam as regras que me levariam ao uma implementação de DAO específica, onde eu poderia tratar e manipular os dados antes da chamada DAO, conforme as necessidades da implementação

- ClienteRepository encapularia DAOClienteOracleImp, DAOClienteMySqlImp, DAOClienteWebServiceImp ,DAOClienteLDAPImp

Que acham ?

gomesrod wrote:Pelo pouco que conheço, algumas das diferenças seriam as seguintes:

1) O estilo da interface é diferente, o repository tem uma carinha de Coleção.
Mais ou menos assim:
userDao.save(User usr); userDao.findById(int userId); userDao.deleteUser(int userId); // Esta interface transmite uma característica de "utilitário para acesso ao BD". userRepository.add(User usr); userRepository.get(int userId); userRepository.remove(User usr); // Já essa outra simula o próprio mecanismo de persistência. Para o restante da aplicação, // é como se o banco de dados fosse um simples objeto, uma lista em memória.


2) O Repository é parte do domínio de negócio, portanto pode ser acessado a partir de um Controller por exemplo. Elimina a necessidade daqueles business objects que não fazem nada além de delegar para o Dao.


Agora, sobre o foco principal... para mim não está claro se o Repository precisaria de um Dao para abstrair a camada de persistência real.

FernandoFranzini wrote:

Se a abstração do Repository é a mesma do DAO, qual a diferença em usar um ou outro modelo?

Veja o livro do DDD do Eric Vans falando sobre o padrão repositório na pagina 147 e compare com o JEE patters - http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
Vc vera q semanticamente falando não existe diferença nenhuma.....o Eric Vans apenas trocou o nome para gerar uma "grupo de padrões" voltados para a aplicação sistemática DDD.
Vc vc até pode fazer assim, mas vai duplicar uma abstração desnecessária...adicionando uma camada polimorfica sem sentido arquitetural...
Vc pode tentar me convencer ao contrario...caso vc justifique ter 2 abstrações polimórficas....e ai?
Descreva em que caso vc haverá diferentes implementações de Repositorios e DAO's.....

rogeriosantos77 wrote:Justificara então eu usar o respository junto com DAO´s para encapular a implementação da infra propriamente dita, então :
Por exemplo, dentro do meu ClienteRepository haveriam as regras que me levariam ao uma implementação de DAO específica, onde eu poderia tratar e manipular os dados antes da chamada DAO, conforme as necessidades da implementação

- ClienteRepository encapularia DAOClienteOracleImp, DAOClienteMySqlImp, DAOClienteWebServiceImp ,DAOClienteLDAPImp

Que acham ?

Hum... acho que entendi...

No que andei lendo o Repository existe como um objeto além do DAO apenas para poder existir dentro do "pacote do domínio" e atender ao DDD... ao delegar as tarefas para o dao... ele não passa de um dao mascarado que pode existir num pacote separado dos daos propriamente dito... vendo assim, consigo entender e concluir que são a mesma coisa...

hum... não sei dizer quando são necessárias duas implementações distintas (DAO e Repository) nem se são realmente necessárias... vou continuar estudando....

valew