Hibernate - Vale a pena abstrair ainda mais ?

This message was edited 2 times. Last update was at 19/11/2007 10:10:21

Ubiquitous language é uma linguagem que todos entendem. No contexto de Domain Driven Design é uma linguagem que a equipe de desenvolvimento e o cliente entendem.

Ex: Se você fala com o cliente do projeto sobre DAO, EntityManager, EJB, JDBC ele vai boiar. Já se voce Fala sobre um RepositorioDeUsuarios ou RepositorioUsuario (prefiro assim), ele pode entender que em algum momento o usuário é armazenado/removido/recuperado por ali.

Baixa o livro gratuito Domain Driven Design quikly disponível no InfoQ e no capítulo 2 fala sobre o assunto com mais profundidade. http://www.infoq.com/minibooks/domain-driven-design-quickly

This message was edited 1 time. Last update was at 19/11/2007 10:11:16

Fábio... olha, nomes são importantes, mas na minha opinião conceitos são mais importantes. Certo? Eu uso o nome DAO só por ser menos verboso. Teve um projeto que usei ContaREP, mas ficou estranho!

Também vejo que a sua opção acoplou conceitos. Creio que a separação de conceitos entre Entidade e Repositories é bem clara. No seu modelo praticamente estamos usando Client para obter Orders. Provavelmente você terá uma interação entre objetos que essa situação ocorre, mas pode ocorrer de você precisar essa mesma busca em outros pontos do sistema. Uma das idéias do repository é poder reaproveitar essas buscas.

Outro ponto: seu modelo nos diz que eu preciso ter uma instância de Client para obter as Orders. Não sei se dá pra concordar com você nesse ponto de "ser mais OO". Pode ter aumentado a coesão, mas lembre-se que com isso o acoplamento aumenta também. Eu injeto services e repositories nas minhas entidades para cumprir objetivos de negócio da entidade, não para fazer a entidade ponto de entrada para buscas...

This message was edited 1 time. Last update was at 19/11/2007 10:30:52

Opa Rodrigo, vamos com calma...

rodrigoy wrote:Fábio... olha, nomes são importantes, mas na minha opinião conceitos são mais importantes. Certo? Eu uso o nome DAO só por ser menos verboso. Teve um projeto que usei ContaREP, mas ficou estranho!

Eu acho que nomes caminham juntos com conceitos. Usar nomes não adequados pode confundir os conceitos empregados, mas isso não é necessariamente o seu caso. Na verdade eu não sei muito bem onde termina o senso comum e começa o gosto pessoal nesse caso.

rodrigoy wrote:Também vejo que a sua opção acoplou conceitos. Creio que a separação de conceitos entre Entidade e Repositories é bem clara. No seu modelo praticamente estamos usando Client para obter Orders. Provavelmente você terá uma interação entre objetos que essa situação ocorre, mas pode ocorrer de você precisar essa mesma busca em outros pontos do sistema. Uma das idéias do repository é poder reaproveitar essas buscas.

Outro ponto: seu modelo nos diz que eu preciso ter uma instância de Client para obter as Orders. Não sei se dá pra concordar com você nesse ponto de "ser mais OO". Pode ter aumentado a coesão, mas lembre-se que com isso o acoplamento aumenta também. Eu injeto services e repositories nas minhas entidades para cumprir objetivos de negócio da entidade, não para fazer a entidade ponto de entrada para buscas...

Eu até entendi o seu ponto aqui, e concordo um pouco com ele, mas não era o meu caso. No exemplo que eu dei, dado um cliente eu quero as suas compras obedecendo algum critério. Poderíamos discutir se o cliente é responsável ou não por me dizer quais foram as suas compras, mas supondo que ele saiba disso (e tenha essa responsabilidade), acho razoável pedir a um cliente que me dê as suas compras. Eu não sei se ficou claro, mas como o meu requisito parte de "dado um cliente...", não haverá pontos no sistema onde essa "busca" não parta de um cliente.

Eu estou longe de sugerir que o cliente seja o ponto de entrada para qualquer compra e que todas as compras devem vir de clientes. Não tenho nada contra o repositório ser usado dentro ou fora de uma entidade.

This message was edited 1 time. Last update was at 19/11/2007 10:41:42

Uma coisa que esqueci de perguntar anteriormente foi: Se os conceitos do EntityManager são apenas de persistência e ficarão encapsulados no DAO, como fica o Criteria nessa história?

Hibernate já tem uma API critéria e Domain Driven Design recomenta os Repositórios utilizando Criterias para as pesquisas.

Soluções:

1 - Deixariamos a API Criteria do Hibernate vazar entre as camadas? Não me cheira muito bem isso.[/list]
2 - Criamos outro Criteria para o Repositório e converteriamos esse Criteria no Criteria do Hibernate adicionando a função de adapter a este Repositório ?
3 - ????

Essas são as razões que me fazem pensar que o Hibernate/JPA (principalmente esta spec) foi criado(a) como uma solução contemplando esses conceitos que vão do Repositorio pra baixo. Como falei no post inicial, EntityManager (O Gerênciador de Entidades

) é justamente o que é um Repositório se propoe (Tá certo o nome ta diferente). A parte do Critéria tem até o mesmo nome e a funcionalidade do DAO/Data Mapper está implementada internamente com a geração das queries, dialetos do banco, etc.

O fato é que por ser um EntityManager genérico com métodos que cheiram persistência, ferra com tudo e IMO acabamos tendo que fazer um bacalhau enorme para encapsular isso tudo e ficar com mais cara de conceitos de negócio e isso que ta me incomodando

Bom, no geral (sempre há exceções) eu não acho isso saudável:

Isso transfere muita responsabilidade aos utilizadores do repositório, além de espalhar esse conceito de "busca" por todos os cantos. Eu prefiro uma interface mais bem definida:

Na implementação do repositorio você usa criterias e specifications.

Fabio Kung ++

This message was edited 1 time. Last update was at 19/11/2007 11:21:45

É dessa forma que se implementa hoje até mesmo no DAO. Acho que é a melhor mesmo

JavaEvangelist Membro desde: 21/01/2004 14:12:54 Mensagens: 468 Offline

emerleite wrote:

Lezinho wrote:

emerleite wrote:Exemplos ?

Um exemplo mais simples e direto de como pode comprometer seu objeto Entity de negócio inserindo diretamente EntityManager, é na construção de testes unitários.

Considerando que EntityManager é uma interface, não vi diferença em coloca-lo no lugar do Repositório para a questão dos testes já que seria possível criar um mock da mesma forma. Não entendi muito bem o seu exemplo.

Com o EntityManager injetado (mock ou não), você teria na mesma lógica espalhado no seu código possíveis ejbqls/HibernateCriterias/Specifications/nativeSQLs ou no melhor dos casos invocações de NamedQueries... tudo junto com o resto de sua lógica.

Ao realizar os unitTests você vai querer testar apenas o pertinente ao método, ou seja, toda a parafernália da persistência vai estar lá no seu design porém ignorada por uso de Mocks.

Isso tudo funciona, mas a fluência do código vai ficar péssima... TDD nisso vai dar dor de cabeça.

O ganho de uma abstração maior, englobando todos os aspectos da persistencia, é evidente.

Lezinho wrote:O ganho de uma abstração maior, englobando todos os aspectos da persistencia, é evidente.

Ótimo ponto Lezinho. Imagina ficar mockando EntityManager: se receber query "SELECT * FROM Client ..." retorne "new List<Client>() ...;". Que inferno.

Isolar tudo isso em repositórios deixa tudo bem mais testável. E TDD é exatamente sobre isso; melhorar continuamente o seu design.

Ok. Me rendo rs rs rs. Vai valer a pena encapsular a utilização do EntityManager no Repositório.