�ltimas mensagens do t�pico "Hibernate - Vale a pena abstrair ainda mais ?"

Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

Estudando sobre Domain Driven Design aprendi sobre Repository, Criteria, etc. Juntamente com os Data Mappers (Famosos DAOs em Java) catalogados por Fowler, percebi que o Hibernate/JPA aparentemente utilizou-se dessa ideia para a cria��o do seu framework.

Conclu� ent�o, que utilizando Hibernate n�o preciso criar RepositorioXXX ou Criterias ou DAOs j� que o Hibernate tem tudo isso a disposi��o atrav�s da Session/EntityManager, Criteria, Dialeto do Banco de Dados e a gera��o autom�tica das instru��es SQL.

Eu sei que a Session/EntityManager � muito gen�rico, serve como reposit�rio de todos os objetos, diferente de um RepositorioCliente por exemplo, mas mesmo assim, ainda vou precisar em algum cen�rio criar classes para o padr�o Repository quando utilizo Hibernate ?

Utilizando a Session/EntityManager na Fachada de Servi�os ou at� mesmo dentro de alguma Entity(DDD) em alguma opera��o de neg�cio que precise de dados, ao meu ver estou utilizando implicitamente todos esses padr�es e implementando da maneira correta.

Sugest�es ?

Re:Hibernate - Vale a pena abstrair ainda mais ?

xandroalmeida — GMT

Eu tenho usado Repositorys diretamente de dentro das Entitys, e dentro do Repository uso diretamente o Hibernate, sem mais abstra��es.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

Pois �. Mas � isso que eu acho n�o fazer sentido.

Por exemplo:
[code]
public class RepositorioUsuario {
private EntityManager em;
public void salvar(Usuario u) {
em.persist(u);
}
}
[/code]
O que eu ganhei com isso ? [b]Nada[/b].

Virou um delegador apenas.

Re:Hibernate - Vale a pena abstrair ainda mais ?

ovelha — GMT

Neste caso da a impress�o mesmo de apenas uma camada a mais, agora vc j� parou para pensar em casos mais complexos?

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

Eu uso o repository s� para buscas... para persistir e para mergear uso o EntityManager... pra mim o EM, j� � uma abstra��o...

Re:Hibernate - Vale a pena abstrair ainda mais ?

xandroalmeida — GMT

Por isso eu tenho um AbstractRepository com as principais fun��es de CRUD. Ai se n�o preciso nada al�m do CRUD, basta extenter e n�o fazer mais nada.

o problema de voc� n�o ter repository � correr o risco de duplicar c�digo. Por exemplo, voc� em v�rias partes do sistema tem que obter o usu�rio � partir do email. Se voc� n�o tem um Repository de Usu�rios, ter� que construir consultas para buscar o usu�rio pelo email por varias partes do sistema.

Re:Hibernate - Vale a pena abstrair ainda mais ?

ronybrand — GMT

Utiliza Spring com HibernateDaoSuport vai ficar bem mais facil de trabalhar com Hibernate, ai ele controla Session/Entity Manager para vc!

Re:Hibernate - Vale a pena abstrair ainda mais ?

xandroalmeida — GMT

[quote=rodrigoy]Eu uso o repository s� para buscas... para persistir e para mergear uso o EntityManager... pra mim o EM, j� � uma abstra��o... [/quote]

Os Repositorys acabam sendo usados para buscas mesmo, acho que � esta a id�ia.

Como eu disse, eu prefiro ter um AbstractRepository com os m�todos de CRUDs b�sicos, para evistar o uso do EM diretamente, mas tamb�m n�o vejo problemas nisso.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

[quote=rodrigoy]Eu uso o repository s� para buscas... para persistir e para mergear uso o EntityManager... pra mim o EM, j� � uma abstra��o... [/quote]
At� entendi mas ai voc� ficaria com reposit�rios incompletos e/ou dupicados. Ex: RepositorioConta s� para pesquisa nas contas e o EntityManager para o crud. N�o ficaria confuso essas classes no seu Domain Model ? Teoricamente caso eu queira utilizar o seu RepositorioConta eu vou procurar uma op��o de salvar minha conta ali, entende ?

Acho que ainda n�o ta legal ....

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

Voc� acha que o EntityManager � uma classe do Domain Model ou da Infra?

Hibernate - Vale a pena abstrair ainda mais ?

nbluis — GMT

O Repository faz al�m de buscas com de filtros sql.

Do tipo.

Busque todas as casas com 3 quartos onde o primeiro quarto tenha a cor rosa e a cozinha tenha uma janela para um bosque com uma macieira e um cavalo branco (apenas um cavalo) .

Uma busca dessas certamente n�o vai poder ser feita apenas com joins e filtros no where....

A� que o repository entra efetivamente.

Entende ??

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

@rodrigoy
Voc� tocou no ponto. Tecnicamente EntityManager seria um Repository so que gen�rico. Por�m, a implementa��o que o Hibernate/JPA fez fica com cara de infra. Ent�o fica parecendo uma mistura das duas coisas, ou seja, responsabilidade demais. O cheiro de infra � t�o grande por causa dos m�todos persist(), merge(), ao inv�s de um adicionar() por exemplo.

Mas de qualquer maneira ainda acho meio esquisito voc� ter um Repository que n�o tem as op��es adicionar() e remover() por exemplo, ficando somente com consultas. Ta certo que poderia ter delegando para o EntityManger fazer isso mais sei l�, parece uma coisia meio bacalhau entende ? O que voc� acha ?

@nbluis
Isso foi falado anteriormente pelo rodrigoy, por�m o problema � justamente este. Um Repository segundo a defini��o � onde a Entity fica guardada ent�o fica estranho eu ter um RepositoryConta para buscar uma conta e depois quando eu for adicionar uma nova conta eu n�o poder usar esse Repository. Deveria se �nico para esse Entity.

Hibernate - Vale a pena abstrair ainda mais ?

nbluis — GMT

Como assim n�o pode chamar o repository?

Vc chama o repository para adicionar, remover ou qualquer coisa dessas.

J� parou para pensar no fato de que nem todas as suas entidade podem ter o adicionar(persist) ?
O Repository � quem controla isso.

Re:Hibernate - Vale a pena abstrair ainda mais ?

faelcavalcanti — GMT

Para as consultas voc� pode utilizar Restrictions, tanto como filtro, como ordena��o!

Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

[quote=nbluis]Como assim n�o pode chamar o repository?[/quote]
N�o quis dizer que n�o pode, s� quis dizer que vai ser apenas uma delega��o, ou seja, um m�todo quase burro.
[quote=nbluis]J� parou para pensar no fato de que nem todas as suas entidade podem ter o adicionar(persist) ?[/quote]
Correto. O que acontece � que o EntitManager me d� todas essas opera��es e esse Repository sugerido como ficaria sendo que o Hibernate j� tem a sua API Criteria ? Teoricamente Quando implementamos um Repositpry temos Criteria tamb�m. N�o j� � isso que o Hibernate faz ?

Hibernate - Vale a pena abstrair ainda mais ?

andre_salvati — GMT

[quote=emerleite]

Conclu� ent�o, que utilizando Hibernate n�o preciso criar RepositorioXXX ou Criterias ou DAOs j� que o Hibernate tem tudo isso a disposi��o atrav�s da Session/EntityManager, Criteria, Dialeto do Banco de Dados e a gera��o autom�tica das instru��es SQL.

[/quote]

Acho que n�o. Os DAOs ainda s�o v�lidos, j� os Repositorios nem tanto...

[quote=emerleite]

Utilizando a Session/EntityManager na Fachada de Servi�os ou at� mesmo dentro de alguma Entity(DDD) ...

[/quote]

Fica meio estranho acessar o EntityManger de dentro de Entities.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Alessandro Lazarotti — GMT

O seu reposit�rio pode cuidar de opera��es mais complexas do que simplesmente fazer um CRUD ou uma busca simples. Para formar um agregado, por exemplo, voc� pode realizar mais de uma consulta no banco.

Um reposit�rio � um elemento ativo no neg�cio e na modelagem, n�o � uma ferramenta de acesso a dados. Ele pode ser modelado com comportamento (m�todos) que fazem sentido quando colocados em um diagrama do dom�nio, pois o objeto em s� pertence ao dom�nio. Um EntityManager n�o pertence a dom�nio algum, e seus m�todos n�o s�o Ubiquitous.

O reposit�rio tbm � um bom lugar para voc� definir seus contratos quando se interage com algo da persistencia (e retornar uma exception para seu cliente da camada). Isso parece melhor do que retornar true/false, null, 1/0, e outras bizarrices.

Colocar EntityManager diretamente nas entidades parece um grande acoplamento entre meios de persistencia e objetos de neg�cio.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

@Lezinho
Concordo com voc�. Ent�o o que eu disse sobre ter no Repository um adicionar que chama o persist() do EntityManager tornando esses m�todos do Repository apenas um m�todo que delega a tarefa e era isso que n�o estava me agradando muito. Mas parece que n�o tem outro jeito.

Mas de qualquer maneira a id�ia do EntityManager n�o seria implementar um Repository s� que gen�rico ? Eu entendo que fica mais Ubiquitous mas n�o sei se vale muito a pena abstrair isso em todos os casos. Talvez na maioria dos casos n�o seja necess�rio. E isso justamente que eu to me perguntando se tem algum caso que vou precisar realmente ...

Exemplos ?

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

Parta do pressuposto que � natural da entidade ela ser "persistente", dessa forma, n�o � comum que uma entidade "salve" ela pr�pria ou outras entidades dentro do comportamento da pr�pria entidade. Minhas entidades n�o dependem do EntityManager, mas minhas fa�ades sim...

Dado o paradigma atual uma das grandes responsabilidades da camada de aplica��o � concentrar o controle de transa��o, seja por AOP, Anota��es, Cont�iner, etc... Assim sendo, � na camada de aplica��o que est� os manager.persist e manager.merge.

Lembre-se tamb�m: s� usamos o EntityManager por causa de ORM, e nossas entidades n�o sabem disso.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Fabio Kung — GMT

Concordo um pouco com o que o Rodrigo disse. Os repositorios trazem bastante valor para agregados e pesquisas complexas. Considerando que voc� n�o est� usando ActiveRecord, voc� n�o vai precisar chamar save/persist/merge dentro dos seus objetos de dom�nio. A� o Reposit�rio n�o precisaria ter o adicionar() que s� delega.

Minha opini�o pessoal � de que n�o � t�o ruim ter m�todos do Reposit�rio que apenas delegam se voc� n�o quiser expor a Session/EntityManager. O Reposit�rio nesses casos fica sendo um "Adapter", mas concordo que isso � um pouco burocr�tico...

De qq forma, [b]Java � burocr�tico mesmo[/b]!

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

[quote=rodrigoy]Parta do pressuposto que � natural da entidade ela ser "persistente", dessa forma, n�o � comum que uma entidade "salve" ela pr�pria ou outras entidades dentro do comportamento da pr�pria entidade. Minhas entidades n�o dependem do EntityManager, mas minhas fa�ades sim...[/quote]
Exatamente isso que eu disse nos posts anteriores. Por�m pensando no Repository, em alguns casos temos refer�ncia dentro da Entity para um reposit�rio, vide esse exemplo [url]http://blog.caelum.com.br/2007/06/09/repository-seu-modelo-mais-orientado-a-objeto/[/url].

E ai � que eu estava me perguntando se ao inv�s do Repository poderia ser sempre o EntityManager substituindo-o por completo. Pelo visto o pessoal ta preferindo e indicando encapsular.

[quote=Fabio Kung]Minha opini�o pessoal � de que n�o � t�o ruim ter m�todos do Reposit�rio que apenas delegam se voc� n�o quiser expor a Session/EntityManager. O Reposit�rio nesses casos fica sendo um "Adapter", mas concordo que isso � um pouco burocr�tico... [/quote]
� o que eu havia dito que eu n�o gostaria j� que na verdade n�o est� me parecendo muito um adapter e t�o apenas um delegate bem simples.

Bem, no pr�ximo projeto vou encapsular o EntityManager em cada Repository espec�fico para ger�nciar os agreggates e as queries complexas pra ver se terei algum ganho com isso. Claro que um ganho que percebo de cara � ficar mais Ubiquitous mas realmente como o F�bio falou, que burocracia heim ....

Re:Hibernate - Vale a pena abstrair ainda mais ?

pcalcado — GMT

Essa discuss�o j� foi feita no GUJ algumas vezes mas acho que 99% das suas d�vidas pr�ticas v�o se reslver se voc� modelar o Reposit�rio como uma interface implementada pelo DAO. O Reposit�rio � um conceito de neg�cios que desta forma vai ser implementado pelo Dependency Inversion Principle (DIP, Uncle Bob).

Re:Hibernate - Vale a pena abstrair ainda mais ?

Alessandro Lazarotti — GMT

[quote=emerleite]Exemplos ?[/quote]

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.

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

O que n�o impediria tamb�m de fazer isso:

Re:Hibernate - Vale a pena abstrair ainda mais ?

mauro_schneider — GMT

[quote=rodrigoy]

Tanto que nem chamo meus repositories de ContaRepository, chamo eles de ContaDAO mesmo. O que interessa � o conceito.

[/quote]

Mas ser� que nome n�o faz parte do conceito ?

Neste caso ContaDAO (Interface) vai estar nas classes de Dominio ?

No meu modo de ver se ContaDao ser chamada de ContaRepository e esta ser injetada do Dominio, fica mais organizado.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

[quote=pcalcado]Essa discuss�o j� foi feita no GUJ algumas vezes mas acho que 99% das suas d�vidas pr�ticas v�o se reslver se voc� modelar o Reposit�rio como uma interface implementada pelo DAO. O Reposit�rio � um conceito de neg�cios que desta forma vai ser implementado pelo Dependency Inversion Principle (DIP, Uncle Bob).[/quote]
Pois �. Pra mim o Repository seria uma interface e n�o uma classe concreta. Mas o pessoal tava sugerindo como se fosse uma classe concreta. Acho que esse teu exemplo do Repository ser a especifica��o (contrato/interface, ou como queira) do DAO uma abordagem v�lida. Mas lembra da tal discuss�o que teve uma vez no GUJ sobre o Hibernate eliminar a necessidade do DAO, j� que o EntityManager/Session faz esse papel de DAO para quase todos os cen�rios? Mas pelo visto n�o morre a necessidade que � o que eu achava que ia acontecer ...

A unica coisa que mudou � que minha interface do componente de acesso a dados ficou Ubiquitous e ao inv�s de escrever os SQL eu uso o Hibernate (Claro, com todas as suas vantagens de lazy-load etc etc etc.)

Acho que viajei na maionese achando que essa estrutura iria mudar .. Me corrijam se eu estiver errado.
[quote=rodrigoy]Tanto que nem chamo meus repositories de ContaRepository, chamo eles de ContaDAO mesmo. O que interessa � o conceito. [/quote]
N�o estariamos deixando de expressar um conceito no c�digo ? Acho que seria melhor que seja ContaRepository mesmo.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

[quote=Lezinho][quote=emerleite]Exemplos ?[/quote]

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.
[/quote]
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.

Re:Hibernate - Vale a pena abstrair ainda mais ?

BiraBoy — GMT

Ubiquitous. O que isso quer dizer mesmo?

Re:Hibernate - Vale a pena abstrair ainda mais ?

Fabio Kung — GMT

[quote=mauro_schneider]Mas ser� que nome n�o faz parte do conceito ?[/quote]
http://www.fabiokung.com/2007/11/12/comments-to-gavin-king-about-ddd-and-repositories/

ps.: odeio fazer isso, mas essa n�o consegui evitar...

[quote=mauro_schneider]No meu modo de ver se ContaDao ser chamada de ContaRepository e esta ser injetada do Dominio, fica mais organizado.[/quote]
Concordo.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

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. [url]http://www.infoq.com/minibooks/domain-driven-design-quickly[/url]

Re:Hibernate - Vale a pena abstrair ainda mais ?

rodrigoy — GMT

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...

Re:Hibernate - Vale a pena abstrair ainda mais ?

Fabio Kung — GMT

Opa Rodrigo, vamos com calma...
[quote=rodrigoy]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![/quote]
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.

[quote=rodrigoy]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...[/quote]
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, [b]dado um cliente[/b] 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 "[b]dado um cliente...[/b]", 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.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

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

Re:Hibernate - Vale a pena abstrair ainda mais ?

Fabio Kung — GMT

Bom, no geral (sempre h� exce��es) eu n�o acho isso saud�vel:
[code]
class Repository {
List busca(Criterio criterio);
}
[/code]
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:
[code]
class Repository {
List getSuspendedClients();
List getOldClients();
// ...
}
[/code]
Na implementa��o do repositorio voc� usa criterias e specifications.

Hibernate - Vale a pena abstrair ainda mais ?

nbluis — GMT

Fabio Kung ++

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

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

Re:Hibernate - Vale a pena abstrair ainda mais ?

Alessandro Lazarotti — GMT

[quote=emerleite][quote=Lezinho][quote=emerleite]Exemplos ?[/quote]

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.
[/quote]
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.[/quote]

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.

Re:Hibernate - Vale a pena abstrair ainda mais ?

Fabio Kung — GMT

[quote=Lezinho]O ganho de uma abstra��o maior, englobando todos os aspectos da persistencia, � evidente.[/quote]
�timo ponto Lezinho. Imagina ficar mockando EntityManager: [i]se receber query "SELECT * FROM Client ..." retorne "new List() ...;"[/i]. Que inferno.

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

Re:Hibernate - Vale a pena abstrair ainda mais ?

Emerson Macedo — GMT

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