Para uma explanação sobre repositórios e especificações bem como sua implementação confira o artigo publicado em
http://progdicas.blogspot.com
A uma explicação de como usar o padrão especificação do DDD junto com o Hibernate.
Tudo ia bem até escrever:
“O seu repositório (DAO) seria assim:”
e colocar o Specification como argumento do metodo da classe agora renomeada Repositorio.
Ou seja, o autor não entendeu a diferença entre Repositorio e DAO.
Nota zero.
Por favor procurar no forum pela diferença.
Bom, eu não sabia desta diferença… Pesquisei no Forum e achei um comentário que me esclareceu bastante (Espero que esteja correto):
[quote=thundercas]Bom, eu não sabia desta diferença… Pesquisei no Forum e achei um comentário que me esclareceu bastante (Espero que esteja correto):
[quote=mochuara]
O objetivo de um framework como Hibernate, assim como um Repositório, é dar a sensação de que os objetos estão na memória, e portanto não preicsam ser acessados (por um DAO no caso). Claro que isso é uma sensação provocada pelo mecanismo de persistencia, vc sabe… utilizar um DAO quebra esse encanto. A diferença do repositório é que na construção de domínio não é permitido que o model tenha qualquer dependencia com infraestrutura. Mas numa aplicação normal não machuca usar o Session do hibernate como “repositorio”.
[/quote][/quote]
O ponto principal que diferencia um Repositorio de um DAO é o onde se define a pesquisa. Num repositorio a pesquisa se define dentro dele e delega a execução. Num DAO ele recebe a pesquisa e a executa. O principal objetivo de um Repositorio é definir as pesquisas. Não executá-las.
Na verdade, um repositório geralmente é uma interface e que é implementada pelo DAO, e conforme Evans no seu livro na pagina 147 cita que “A implementação de um repositório vai variar muito, dependendo da tecnologia que está sendo usada para a persistência e a infra-estrutura existente, O ideal é ocultar do cliente (porém não do desenvolvedor do cliente) todo o funcionamento interno para que o código do cliente seja o mesmo independente de os dados relacional ou simplesmente mantidos em memória.” Com respeito a especificação, um repositório deve ser bastante flexível com respeito a que consultas ele pode executar, como falei mostrarei no próximo post como fazer a implementação da especificação com o repositório a ponto de podermos casar diversas Especificações de forma a conseguir efetuar uma consulta um pouco mais complexa.
Att.
[quote=thundercas]Bom, eu não sabia desta diferença… Pesquisei no Forum e achei um comentário que me esclareceu bastante (Espero que esteja correto):
[quote=mochuara]
O objetivo de um framework como Hibernate, assim como um Repositório, é dar a sensação de que os objetos estão na memória, e portanto não preicsam ser acessados (por um DAO no caso). Claro que isso é uma sensação provocada pelo mecanismo de persistencia, vc sabe… utilizar um DAO quebra esse encanto. A diferença do repositório é que na construção de domínio não é permitido que o model tenha qualquer dependencia com infraestrutura. Mas numa aplicação normal não machuca usar o Session do hibernate como “repositorio”.
[/quote][/quote]
Correto, mas a implementação do repositório faz com que possamos encapsular a forma como o cliente efetua a consulta e com as Especificações podemos fazer que as consultas do cliente possam ser especificadas conforme o que o cliente deseja, simplificando na verdade um conjunto de filtros, conforme falei em meu artigo, a lógica de obter clientes com fatura em atraso fica encapsulada, mesmo usando a session do hibernate como um repositorio a configuração do filtro por meio da api criteria, fica esparamada no codigo, por exemplo você pode ter uma tela onde é necessário saber quem são os clientes que estam com fatura em atraso, ai você pega a session cria a criteria e configura ela assim:
criteria.add(Restrictions.le("dataEmissao",new Date());agora no relatório você também tem que verificar as pessoas que estão em atraso, então REPETE o código assim também no relatório, isto torna o código mais dificil de manter.
Quando você usar um repositorio que permite o uso de Especificações, você encapsula a configuração da criteria numa especificação, e passa para o repositorio sendo que ele então com base em suas Especificações, configurará a criteria e retornará a lista desejada, digamos que agora mudou a lógica de obter clientes que estam em atraso sendo que devemos considerar também o valor, a modificação se torna fácil visto estar centrada toda a lógica de verificação de um cliente em atraso no objeto que é uma especificação.
Neste ponto a especificação acaba agindo como um filtro para que o repositório possa filtrar os resultados e repassar para o cliente, mas a Especificação também pode ser usada para efetuar a validação, no artigo expliquei isto também.
Poderia então nos citar como tem feito, com exemplos, para podermos dialogar sobre o assunto?
Na verdade, um repositório geralmente é uma interface e que é implementada pelo DAO, e conforme Evans no seu livro na pagina 147 cita que “A implementação de um repositório vai variar muito, dependendo da tecnologia que está sendo usada para a persistência e a infra-estrutura existente, O ideal é ocultar do cliente (porém não do desenvolvedor do cliente) todo o funcionamento interno para que o código do cliente seja o mesmo independente de os dados relacional ou simplesmente mantidos em memória.” Com respeito a especificação, um repositório deve ser bastante flexível com respeito a que consultas ele pode executar, como falei mostrarei no próximo post como fazer a implementação da especificação com o repositório a ponto de podermos casar diversas Especificações de forma a conseguir efetuar uma consulta um pouco mais complexa.
[/quote]
Veja se isso é coerente com isto http://martinfowler.com/eaaCatalog/repository.html. Não é.
E por favor leia o material no guj sobre DAO vs Repositorio antes de responder de novo.
Na verdade, um repositório geralmente é uma interface e que é implementada pelo DAO, e conforme Evans no seu livro na pagina 147 cita que “A implementação de um repositório vai variar muito, dependendo da tecnologia que está sendo usada para a persistência e a infra-estrutura existente, O ideal é ocultar do cliente (porém não do desenvolvedor do cliente) todo o funcionamento interno para que o código do cliente seja o mesmo independente de os dados relacional ou simplesmente mantidos em memória.” Com respeito a especificação, um repositório deve ser bastante flexível com respeito a que consultas ele pode executar, como falei mostrarei no próximo post como fazer a implementação da especificação com o repositório a ponto de podermos casar diversas Especificações de forma a conseguir efetuar uma consulta um pouco mais complexa.
[/quote]
Veja se isso é coerente com isto http://martinfowler.com/eaaCatalog/repository.html. Não é.
E por favor leia o material no guj sobre DAO vs Repositorio antes de responder de novo.[/quote]
O padrão dado por Flower é exatamente o que foi abordado no artigo, a criteria que é passada do cliente para o repositorio é o mesmo que a especificação do Eric Evans, e o Repositório retorna em uma lista todos os que satisfazem o criterio (Especificacao) não entendo a sua opnião você anteriormente citou:
O ponto principal que diferencia um Repositorio de um DAO é o onde se define a pesquisa. Num repositorio a pesquisa se define dentro dele e delega a execução. Num DAO ele recebe a pesquisa e a executa. O principal objetivo de um Repositorio é definir as pesquisas. Não executá-las.E agora apresenta o padrão do Flower que tem a configuração das restrições sobre os dados em uma criteria a parte do repositório.
Quais são os pontos que estão divergentes desta abordagem? Como apresentado no artigo, temos uma Especificação que o cliente usa para dizer o que ele quer e o repositório se vira em retornar o resultado conforme o cliente deseja, pouco importando se a implementação do repositório está operando em memória ou sob um conjunto de dados de um banco ou mesmo um XML.
Na verdade, um repositório geralmente é uma interface e que é implementada pelo DAO, e conforme Evans no seu livro na pagina 147 cita que “A implementação de um repositório vai variar muito, dependendo da tecnologia que está sendo usada para a persistência e a infra-estrutura existente, O ideal é ocultar do cliente (porém não do desenvolvedor do cliente) todo o funcionamento interno para que o código do cliente seja o mesmo independente de os dados relacional ou simplesmente mantidos em memória.” Com respeito a especificação, um repositório deve ser bastante flexível com respeito a que consultas ele pode executar, como falei mostrarei no próximo post como fazer a implementação da especificação com o repositório a ponto de podermos casar diversas Especificações de forma a conseguir efetuar uma consulta um pouco mais complexa.
[/quote]
Veja se isso é coerente com isto http://martinfowler.com/eaaCatalog/repository.html. Não é.
E por favor leia o material no guj sobre DAO vs Repositorio antes de responder de novo.[/quote]
Procurei e vi sobre o padrão do Flower, conforme comentei, não achei diferenças sobre a sua implementação, poderia então dar um exemplo de como tem de ser feito?
[quote=euprogramador]
[quote]
Veja se isso é coerente com isto http://martinfowler.com/eaaCatalog/repository.html. Não é.
E por favor leia o material no guj sobre DAO vs Repositorio antes de responder de novo.[/quote]
Procurei e vi sobre o padrão do Flower, conforme comentei, não achei diferenças sobre a sua implementação, poderia então dar um exemplo de como tem de ser feito?[/quote]
Faça assim, continue usando o codigo do blog mas não chame de repositorio. Ai não temos nenhum problema (fora o sindrome de DAO, mas … )