| Autor |
Mensagem |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 17/01/2011 23:58:23
|
diego.dfsd
HelloWorld
Membro desde: 26/10/2009 17:51:24
Mensagens: 10
Offline
|
Em uma discussão com uma amigo ele me perguntou pq eu não posso ter a implementação do repositório dentro do próprio dominio e eu expliquei que iria contra a idéia de que o dominio nao pode depender de nenhum framework ou projeto, mas ele colocou da seguinte forma:
A interface ou classe abstrada do repository pertence ao domínio até ai ok e pq eu não posso ter também a implementação do repositório lá, sendo que o meu repositório receberia via IoC meu DAO ou meu objeto de contexto do ORM. A dúvida ficou, será que alguém tem alguma colocação interessante a fazer sobre isso?
|
|
|
 |
|
|
![[Post New]](/templates/default/images/icon_minipost_new.gif) 18/01/2011 08:16:35
|
Adriano Almeida
JavaEvangelist
![[Avatar]](/images/avatar/080eb9c2c128e1337fcc84d8680f404c.jpg)
Membro desde: 13/09/2006 15:29:34
Mensagens: 386
Offline
|
Oi Diego, td bem?
A questão não é nem que você não possa, dentro dos suas entidades e value objects utilizar algum framework. Se for necessário para a tarefa, não tem o pq nao utilizar. O problema é o acoplamento gerado entre essas classes, diminuindo a testabilidade.
A ideia pelo que entendi que vc quer fazer é no fundo um Active Record, onde o próprio objeto saberia como se persistir.
Recentemente, o Philip Calçado postou no blog dele umas dicas sobre repositories, questão de nomenclaturas e como melhor ajustá-lo ao domínio da sua app. Vale dar uma lida lá e posta aqui depois o que você acha para continuarmos a discussão.
|
Twitter: @adrianoalmeida7
http://ahalmeida.com
http://blog.caelum.com.br

|
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 18/01/2011 08:22:46
|
alabeduarte
Thread.start()
Membro desde: 18/10/2009 12:51:30
Mensagens: 38
Offline
|
Olá Diego.
Acho que o repository não deve habitar o meu domínio, exceto se eu precisar executar alguma regra de negócio específica que implica alguma consulta na minha base.
Porque, querendo ou não, o repository na prática, ele não só traz o que "preciso" mas também contém toda a responsabilidade de conectividade com banco, por exemplo, montagem de query e tal, e acho que ao crescer o projeto vai bagunçar um pouco o meu domínio...
veja abaixo um exemplo prático, onde preciso cadastrar um usuário com email único, ai antes valido o email dele, se está formatado e se já existe um email cadastrado na base, se for td OK eu peço ao dao genérico (meu repository) para persistir:
OBS: esse exemplo usa VRaptor e Hibernate, mas qualquer dúvida posta aqui:
espero ter ajudado.
sugiro que faça esse mesmo questionamento no www.tectura.com.br pois la o foco maior é arquitetura, daí mais gente pode entrar na discussão!
Se postar la me avisa que vou postar esse mesmo tópico la, afinal tbm quero participar dessa discussão, que é mto interessante, rs
abraço!
This message was edited 6 times. Last update was at 18/01/2011 08:31:45
|
Alabê Duarte
SCJP 6
@alabeduarte
http://br.linkedin.com/in/alabeduarte
http://alabeduarte.blogspot.com
http://javabahia.blogspot.com
http://www.portaljavabahia.com
|
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 18/01/2011 10:09:39
|
diego.dfsd
HelloWorld
Membro desde: 26/10/2009 17:51:24
Mensagens: 10
Offline
|
A questão na verdade é: Eu posso ter a implementação do meu repositório dentro do meu domínio, assim como tenho seu contrato? Uma vez que eu vá injetar no meu repositório o meu DAO ou meu objeto de contexto no caso de um ORM como Hibernate. Seria o mesmo que ter a class UserDao no meu dominio... Isso ao meu ver não cria acoplamento já que a UserDAO recebeu por IoC o objeto que de fato vai consultar e persistir dados pra mim. Eu não trabalho desta forma mais em uma discussão fui questionado sobre isso e a minha respota se resumia ao fato do acoplamento e também dos termos usados já que no dominio temos que usar termos de dominio "ubiquitous language" e também o lance da dependência do domínio. Mais não sei se isso é suficiente pra justificar já que com a injeção do objeto de persistência muito disso acaba.
|
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 18/01/2011 11:26:50
|
peerless
GUJ Master
![[Avatar]](/images/avatar/5b2a8f2b014bb326fd82ee313704e78c.jpg)
Membro desde: 22/01/2007 14:52:26
Mensagens: 1391
Localização: Porto Alegre / RS
Offline
|
diego.dfsd wrote:A questão na verdade é: Eu posso ter a implementação do meu repositório dentro do meu domínio, assim como tenho seu contrato? Uma vez que eu vá injetar no meu repositório o meu DAO ou meu objeto de contexto no caso de um ORM como Hibernate. Seria o mesmo que ter a class UserDao no meu dominio... Isso ao meu ver não cria acoplamento já que a UserDAO recebeu por IoC o objeto que de fato vai consultar e persistir dados pra mim. Eu não trabalho desta forma mais em uma discussão fui questionado sobre isso e a minha respota se resumia ao fato do acoplamento e também dos termos usados já que no dominio temos que usar termos de dominio "ubiquitous language" e também o lance da dependência do domínio. Mais não sei se isso é suficiente pra justificar já que com a injeção do objeto de persistência muito disso acaba.
Você quer dizer a nivel "fisico" das classes/pacotes referentes a implementação ?
Se for isso, não há certo e errado pois, teoricamente, a implementação não afeta seu dominio, visto que ele é injetado via IoC e a dependencia que esta lá é a interface. Mas, um bom exercicio para separar as coisas é: há imports das classes de implementação dentro das classes de domínio? Não? Então deve estar num pacote diferente!
|
follow me
pitacos
"The most problems that teams face are about communication, and all the others are too." - Dan North
|
|
|
 |
![[Post New]](/templates/default/images/icon_minipost_new.gif) 16/06/2011 12:57:59
|
giulianocosta
JavaEvangelist
Membro desde: 11/08/2003 09:59:28
Mensagens: 442
Offline
|
alabeduarte wrote:Olá Diego. abraço!
Neste caso não é o Repository que deveria acessar o DAO ou então o DAO Implementar o Repository?
This message was edited 2 times. Last update was at 16/06/2011 12:59:31
|
Giuliano Costa
Programador |
|
|
 |
|
|