Injeção de Dependência em Domain Model (ServiceLayer+DomainModel+Repository)

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

Lezinho wrote:

Você não esta sendo claro, ou não esta entendendo.

Esqueceu de levantar a possibilidade de que vc não esteja entendendo. Dê uma olhada na aplicação de referência que te falei e nos exemplos de JBoss Seam (que não são poucos). Depois discutimos....

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

De fato não olhei estes codigos, assim como também não sei pq deveria. Não tenho dúvidas de como usar "repository", e sim "tinha" de como injeta-los no load de algum framework de persistencia (o que foi resolvido via Aspect).

Portanto Taz, dispenso a discussão, o foco desta thread não foi este. Quem achou estranho usar repository em entity foi você (o que o Shoes desmistificou muito bem).

Se você esta com dificuldade de entender repositories em entities, abra uma thread sobre isso.

Boa Sorte.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

Belez...

"O pior cego é aquele que não quer ver" (ditado popular)

Abraço e boa sorte (vc vai precisar se não estudar os exemplos)

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

Taz, eu sei como o Hibernate trabalha com interceptors, tbm sei como delegar isso para service.

Contudo não quero dependencia dos interceptors Hibernate (eu posso instanciar minha entidade atraves de "new", nesta caso o Interceptor do hibernate não me ajudaria) e tbm não quero associar metodos de negocios do repositorio na ServiceLayer, mas sim na minha entidade de domínio. Eu não preciso ler fontes dos exemplos do Hibernate para isso, sei o que quero ou não fazer, assim como não sei de nenhuma literatura mencionando que o que fiz esta quebrando algum conceito OO.

"O pior orador é aquele que se pronuncia sem necessidade alguma"

Taz wrote:

Belez...

"O pior cego é aquele que não quer ver" (ditado popular)

Abraço e boa sorte (vc vai precisar se não estudar os exemplos)

O problema é que as duvidas dele nao sao referentes ao Sean mas sim se tem como aplicar DDD com o Sean. Ai faz sentido ter repositorios dentro dos entities (entities do DDD).

]['s

This message was edited 1 time. Last update was at 06/10/2007 16:39:57

Você entendeu Fabio, é isso mesmo a duvida que tinha quando criei o tópico.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

fabio.patricio wrote:

Taz wrote:

Belez...

"O pior cego é aquele que não quer ver" (ditado popular)

Abraço e boa sorte (vc vai precisar se não estudar os exemplos)

O problema é que as duvidas dele nao sao referentes ao Sean mas sim se tem como aplicar DDD com o Sean. Ai faz sentido ter repositorios dentro dos entities (entities do DDD).

]['s

Ok, vamos falar em DDD.

Seguem trechos do capítulo "Repositories" do Livro do Eric Evans (Domain Driven Design Complexity In Software):

Onde ele fala que são os Entitys que acessam os malditos Repositories!? Todos os diagramas que ele desenha no livro mostram os "Clients" acessando os REPOSITORIES.

Evans wrote:Clients request objects from the REPOSITORY using query methods that select objects based on
criteria specified by the client, typically the value of certain attributes. The REPOSITORY retrieves
the requested object, encapsulating the machinery of database queries and metadata mapping.

(...)

Provide REPOSITORIES only for AGGREGATE roots
that actually need direct access. Keep the client focused on the model, delegating all
object storage and access to the REPOSITORIES.

Sabe o que são AGGREGATES!? Procure no mesmo livro que ele te explica.

Evans wrote:
A REPOSITORY "contains" all instances of a specific type, but this does not
mean that you need one REPOSITORY for each class.

Traduzindo: Vc não precisa criar um repositório para cada classe.

Evans wrote:
It is tempting to commit after
saving, for example, but the client presumably has the context to correctly initiate and
commit units of work. Transaction management will be simpler if the REPOSITORY keeps its
hands off.

Traduzindo: Como ficaria o controle da transação se ele não fosse feito pelo cliente!?

E caso vc ainda acredite que esteja subvertendo seu modelo de domínio, o que é muito difícil quando se faz o uso correto do Hibernate...

Evans wrote:In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven
design and let go of the specifics when the framework is antagonistic. Look for affinities between
the concepts of domain-driven design and the concepts in the framework

Por esses e outros motivos, repito...

Taz wrote:
Continua estranho, Entitys dependendo de Repositories....

This message was edited 3 times. Last update was at 07/10/2007 22:57:04

Capacidade de abstração, ou neste caso a falta dela, é uma coisa muito interessante. É fácil perceber quando algum trecho foi pego sem entendimento do contexto (especialmente quando o contexto é composto por 500+ páginas de texto denso) pela forma como alguém se atem à trechos que sozinhos não têm qualquer significado.

Entity é um padrão, página 89. Repository é um padrão, página 147. Aggregate também, página 125. Não existe um padrão 'client'. por que será? Porque o cliente de algo é simplesmente o que precisa de acesso a este, no caso específico cliente pode ser um Entity. Claro que poderiam haver diagramas mostrando cada uma das possibilidades, entity x repository, service x repository, specification x xrepository... só que haveriam algumas dezenas de páginas a mais a toa.

O texto não traz uma definição de 'cliente', talvez porque... uhm... seja bem obvio quando se tenta.. uhm... ler o dito cujo. Por exemplo quando factories são definidas temos:

But shifting responsibility to the other interested party, the client object in the application, leads to even worse problems. The client knows what job needs to be done and relies on the domain objects to carry out the necessary computations. [...] Even worse, if the client is part of the application layer, then responsibilities have leaked out of the domain layer altogether.

ou seja: o cliente pode ser Camada de Aplicação, mas não necessariamente.

Mas para entender mais profundamente o texto de Evans (coisa que só é necessária quando você está estudando DDD em um nível mais profundo ou quando precisa refutar uma desinformação, que é o caso) é necessário pesquisar no seu antecessor, amplamente referenciado por este: Fowler no seu POEAA. E uma das coisas mais legais do Fowler é que ele consegue responder este tipo de dúvida com um exemplo claro, como este retirado do livro (pagina 325, no capítulo sobre Repository):

Veja que curioso: uma entidade referenciando a seu próprio Repositório. Onde mesmo que havia visto isso? E veja só, ainda usa Registry.

pcalcado wrote:Veja que curioso: uma entidade referenciando a seu próprio Repositório. Onde mesmo que havia visto isso? E veja só, ainda usa Registry.

Uma coisa que vem ficando cada vez mais frequente no GUJ é certos usuários acharem que só eles leram os livros/artigos/papers/coloque aqui sua fonte preferida. Essa resposta do Taz fazendo como se ele fosse o unico e ter lido esse livro me fez procurar o e-mail da primeira vez que eu ouvi falar dessa obra do Evans. Quem me falou disso a primeira vez foi o Marcos Pereira (usuario aqui do GUJ tb) la em 2004 acredito que pouco tempo depois do livro ter sido lancado.

Ps.: Desculpem o desabafo, mas esse tipo de coisa no GUJ vem se tornando frequente e enche um pouco o saco.

]['s

Eu tenho quase certeza que a pimeira referência que vi foi aqui no GUJ pelo cv (e vindod e quem vem não estranharia se fosse a primeira vez que isso apareceu num site em português

). Infelizmente o grande apagamento dos posts de uns dois anos atrás levou a mensagem para o limbo.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

fabio.patricio wrote:

Uma coisa que vem ficando cada vez mais frequente no GUJ é certos usuários acharem que só eles leram os livros/artigos/papers/coloque aqui sua fonte preferida.

Não deveria haver motivos para mágoas. Eu não disse que só eu havia lido...

Quanto ao outro rapaz, percebo certa rispidez em sua réplica, o que já é um comportamento histórico que pode ser ocasionado por uma certa insegurança.... Por outro lado, o mesmo reclama de lidar com pessoas que não se atêm à bibliografias. Quando encontra alguém que lê, deveria ter uma postura mais aberta...

Uma pena que ele não percebe que o Hibernate converte aquilo que ele escreveu:

por isso (obviamente em um contexto "managed")...

Ou seja, o Hibernate contém o próprio Repositorio em si...

Lembrem-se:

Evans wrote:In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven
design and let go of the specifics when the framework is antagonistic. Look for affinities between
the concepts of domain-driven design and the concepts in the framework

This message was edited 5 times. Last update was at 08/10/2007 01:30:26

Após aquele post todo cheio de referências e autoridade completamente furado (e pedir 'abertura' para engolir sua presunção) colar um trecho de um livro que já mostrou que não entende (ou será 'leu'?) é muita cara de pau.

Quem quiser entender melhor sobre Hibernate & Repositories é legal olhar a lista de DDD, o que a pessoa escreveu aí em cima (pra variar) não condiz com a realidade da técnica. O trecho que ele postou substitui Registry por algum meio automático (talvez IoC) de injeção, mas a tecnologia utilizada não tem nada a ver com a aplicação ou não do padrão. Repositories podem ser criados para lidar diretamente com Hibernate, JDBC, search engines ou não, provavelmente delegando seu trabalho à DAOs e DataMappers em geral. Mas nem adianta tentar refutar com argumentos ou até mesmo referências bibliográficas, como se pôde perceber. O bichinho não anda, simples assim.

O outro rapaz aqui (que você já chamou de desonesto neste fórum só por birra) não precisa ter insegurança, pelo menos não quanto à você. Seu histórico aqui já o condena (inclusive profissionalmente, mas tudo bem, você não revela seu nome exatamente para não te reconhecerem, certo?), isso sem contar o portal Java...

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

Apenas respondendo a sua pergunta Taz, sim eu conheço o que é Aggregate, assim como tbm sei que Repository não é um para cada classe. Agora o que não sei mesmo é o que isso tem haver com o que tenho postado ou oq já rolou neste tópico.

Alguma vez afirmei que iria construir repositorios a torto direito para cada entidade minha?

E que porcaria que você andou digitando sobre "Clients"?

Quanto aos "clients", apenas completando o que Shoes já disse... vale comentar tbm que além de usar uma entidade (People), no livro de Fowler (POEAA) ele tbm usa duas classes "Strategy" com um Repository, o que nos mostra a flexibilidade do padrão.

Mas é claro, não espero que Taz concorde com estas afirmações... Já discordou de mim, do Fabio Kung, do Sergio, do Phillip, do fabio.patricio, não duvido que ele discorde de Fowler tbm...

Lezinho wrote:
Mas é claro, não espero que Taz concorde com estas afirmações... Já discordou de mim, do Fabio Kung, do Sergio, do Phillip, do fabio.patricio, não duvido que ele discorde de Fowler tbm...

Só é bom focarmos que discordar é ótimo. Eu discordo do Fowler bastante em DSLs, por exemplo. O ponto é ter um mínimo de respeito pelos outros e darmos base às nossas discordâncias, seja usando uma bibliografia ou argumentando. Pela minha experiência muitas discordâncias contra conceitos são na verdade falta de entendimento (desconfio que meu ponto de divergência com a coisa das DSLs seja exatamente porque ainda não as compreendo bem) e uma conversa e/ou debate ético e profissional são proveitosos para todos.

O que não dá é atirar pedra em todo mundo sem sequer entender o que fala.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 718 Offline

O problema Phillip é quando o "discordar" parece ser mais importante do que "compreender". Só depois de compreender um problema podemos "discordar" de alguma solução para tal, o que não ocorreu por aqui.

PS: Você não apóia o uso de DSLs ? Eu particularmente detestava, até conhecer o Drools e como fazer regras de segurança com ele (o ruim não eram as DSLs e sim como cria-las , IMHO).

Notícias, artigos e o maior fórum brasileiro sobre Java