Qual a importancia de se utilizar JPA ao invés de Hibernate?

Calma que eu não disse que vc não era feliz, apenas usei uma expressão. Nem te conheço, como posso dizer uma coisas destas.

Eu que eu acho é que a abstração da persistência que o Hibernate, por exemplo, fornece é mais que o suficiente.
Então porque não usar uma classe Repository apenas e implementar a buscas usando o Hibernate diretamente.

Senão eu tenho a impressão se estar usando a abstração da abstração da abstração da .....
E ter um repositório de queries, da maneira proposta, não me parece promover o reuso.

sergiotaborda wrote:

um lugar onde se guardam e retornam objetos de qualquer tipo é um DomainStore. É por isso que vc consegue criar uma implementação baseada no Hibernate porque ele tb é um DomainStore. Vc está simplesmente desacoplando o conceito da implementação. Mas ao trocar o nome do conceito vc está fazendo um mal a si mesmo.

O repositório é um objeto que cria criterios e os envia ao DomainStore para serem executados.
No seu caso, vc tem uma classe com métodos estáticos que lhe dão a query que precisa e executa em cima do domainStore ( o que vc chama de reposiotorio é na realidade um DomainStore).

A sua arquitetura não tem Repositorios.

Vc não tem 10928239289 repositorios mas tem 10928239289 métodos estáticos numa classe. Qual vc acha que é melhor prática ?
Um consulta rápida na internet lhe mostrará que coisas estáticas são evil. A principal razão é que não são testáveis (porque não são "mokáveis").
Aposto que vc não tem testes para essa classe.

hmmm, 10928239289 métodos estáticos

vc tem certeza que leu parte do codigo que coloquei aqui ?? te desafio a achar 1 metodo estatico sequere, fora o padrao singleton, que vc mesmo sabe que e' boa pratica.

Nao ha metodos estaticos, nao ha necessidade deles, meus objetos sao concretos,

O que tenho e uma fachada, o que e' outro padrao.

Queries e' uma fachada, serve apenas como concentrador para os varios objetos do tipo Query, como o PessoaQuery.

esses objetos sao singleton, pq nao vejo necessidade de instanciar mais de 1.

Queries seria o mesmo que uma fabrica de PessoaQuery, mas como PessoaQuery e' um singleton, ele nao pode ser conciderado fabrica.

............

Quanto ao nome, como disse, o nome pode ser outro, mas o q me atenho aqui sao ha boas praticas...

e gostaria que me disesse onde esta a ma pratica ? e pq eu deveria usar

new PessoaQuery (ou new RepositoryPessoa)
new OutroQuery (ou new RepositoryOutro)
??

quando posso fazer "queries." e deichar o eclipse me trazer um atalho para a lista com todos os objetos desta categoria ?

nao gosta de fachadas ? paciencia, prefere ter q saber o caminho e o nome de cada Repository ou Query, parabens pra vc, eu prefiro nao ter q me preucupar com isso

Haa e seguindo o padrao fachada... o acesso aos PessoaQuery sao livres, e vc pode nao utilizar o Queries (que e' apenas o concentrador) e utilizar outro caminho para chegar la

Alexandro.Almeida wrote:Calma que eu não disse que vc não era feliz, apenas usei uma expressão. Nem te conheço, como posso dizer uma coisas destas.

Eu que eu acho é que a abstração da persistência que o Hibernate, por exemplo, fornece é mais que o suficiente.
Então porque não usar uma classe Repository apenas e implementar a buscas usando o Hibernate diretamente.

Senão eu tenho a impressão se estar usando a abstração da abstração da abstração da .....
E ter um repositório de queries, da maneira proposta, não me parece promover o reuso.

O Repositorio e' reusavel sim... tenho ele sem mudar 1 linha em mais de 10 projetos...

Os objetos utilitarios como HiberanteQuery, as interfaces, Queryable, QueryableList, sao todas reutilizaveis.... e tambem os tenho em mais de 10 projetos

A unica parte que nao e' reutilizavel e' o EntidadeXQuery obviamente, pois ele guarda a consulta de cada dominio,
e tb ele he trabalho nenhum de fazer, e ele nada mais faz q uma consulta ao hiberante normal, fazendo um DetachedCriteria, e retornando um HibernateQuery<EntidadeAlvo>(dc).list() por exemplo..

O pacote esta pronto, o reuso e' grande sim.

e so tenho q criar uma DetachedCriteria, e encapsultar em um HibernateQuery

This message was edited 1 time. Last update was at 18/03/2010 10:51:32

sergiotaborda wrote:

O queries faz parte da camada de persistencia, e vem justamente para não ter q existir 10928239289 repositorios e existir apenas 1, o único objetivo é desassociar as consultas do repositorio e assim não ter q existir vários locais, ou seja, varios repositorios.

Errado. Primeiro as queries fazem parte da camada de dominio. É um erro comum achar que fazem parte da persistencia, mas não fazem. Elas mudam conforme as regras do dominio e conforme a organização do dominio, logo são da camada de dominio.
Segundo, tudo bem que desassocie as consultas do local onde os objetos estão (DomainStore) , mas o problema aqui é a criação e controle dessas queries, não as queries em si, nem o DomainStore. E é ai que entra o padrão Repository

Não é uma questão de ser legal ou não. É uma questão de ser flexivel, desacoplado, de facil manutenção e testável.

ou eu me expressei mau, ou vc nao entedeu, mas vou explicar novamente....

o que quis dizer e' que os objetos auxiliares para montagem das consultas, sao parte da camada de persistencia, e por isso eles sao bem definidos e separados do projeto.

Os EntidadeXQuery, realmente sao da camada de dominio, e de persistencia ao mesmo tempo, eles ficam no lemiar, eles fazem realmente limite com as duas camadas.

sua interface externa e' para camada de dominio, porem sua implementacao usa a camada de persistencia.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Alessandro Lazarotti wrote:

sergiotaborda wrote:O JPA nasceu como uma alternativa OO ao JDBC mas ao contrario deste ele nasceu falho. O conceito de Native Query é completamente idiota
porque mata o objetivo de ter um mecanismo portável entre bancos. Da mesma forma que o JDBC precisa de um mecanismo para o adquar a vários bancos o JPA precisa do mesmo. O Hibernate não precisa.

Pq nasceu falho e o que isso tem haver com nativeQuery?

JPA = Java Persistance API. Você só persiste em banco de dados ?
Supondo que sim, o JPA abstrai a sintaxe nativa do banco ? Não. Ele usa um sub conjunto da SQL que pertende ser universal,mas todos sabemos que isso é furada. é por isso que precisa das nativeQuery. Vc manda o encasuplamento (não era suposto vc saber que está usando um banco) e a portabilidade ( não era suposto saber qual banco usa). Isso é pior que JDBC. Pelo menos em JDBC eu posso criar DAOs para os diferentes bancos.

Na verdade o próprio Hibernate tbm tem suporte a queries nativas através de session.createSQLQuery, exatamente da mesma forma que entityManager.nativeQuery.

O problema não é se tem nativeQuery, o problema é o não encapsulamento. O Hibernate é um produto para banco de dados. É um ORM.
A JPA não tem que ser um ORM, mas ela está limitada a ser. Conceitos como Join poderiam ser mais agnosticos, mas eles são desenhados com banco de dados em mente.

A JPA é tecnicamente mais limitada que o Hibernate. Ambos têm o mesmo alvo: banco de dados.
Então a unica coisa que faria usar o JPA seria uma independencia maior (que ele não tem) tanto em termos de modelagem, como em termos de execução. Por exemplo, se o JPA não fosse apenas para banco de dados, valeria a pena. Ou se ele fosse realmente agnóstico. Caso contrário o hibernate já provê as mesmas funcionalidades.

Por outro lado o JPA não faz parte do JEE, logo, vc é tão livre de o escolher como escolher o hibernate ou outro qq ORM.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Lavieri wrote:

sergiotaborda wrote:

um lugar onde se guardam e retornam objetos de qualquer tipo é um DomainStore. É por isso que vc consegue criar uma implementação baseada no Hibernate porque ele tb é um DomainStore. Vc está simplesmente desacoplando o conceito da implementação. Mas ao trocar o nome do conceito vc está fazendo um mal a si mesmo.

O repositório é um objeto que cria criterios e os envia ao DomainStore para serem executados.
No seu caso, vc tem uma classe com métodos estáticos que lhe dão a query que precisa e executa em cima do domainStore ( o que vc chama de reposiotorio é na realidade um DomainStore).

A sua arquitetura não tem Repositorios.

Vc não tem 10928239289 repositorios mas tem 10928239289 métodos estáticos numa classe. Qual vc acha que é melhor prática ?
Um consulta rápida na internet lhe mostrará que coisas estáticas são evil. A principal razão é que não são testáveis (porque não são "mokáveis").
Aposto que vc não tem testes para essa classe.

hmmm, 10928239289 métodos estáticos

vc tem certeza que leu parte do codigo que coloquei aqui ?? te desafio a achar 1 metodo estatico sequere, fora o padrao singleton, que vc mesmo sabe que e' boa pratica.

Não. Vc está assumindo coisas que eu nunca disse.
O padrão não pode ser boa prática ou má prática.O uso dele é que pode. Quando vc usa Singleton em java.lang.Runtime é boa prática.
Quando vc usa nos seus XXXQuery é má prática.

Nao ha metodos estaticos, nao ha necessidade deles, meus objetos sao concretos,

O que tenho e uma fachada, o que e' outro padrao.
public class Queries { public PessoaQuery forPessoa() { return PessoaQuery.getInstance(); } }

Queries e' uma fachada, serve apenas como concentrador para os varios objetos do tipo Query, como o PessoaQuery.

Get your patterns straight.
Queries não é uma fachada. É um ServiceLocator

esses objetos sao singleton, pq nao vejo necessidade de instanciar mais de 1.

Pois. Esse é um erro comum.
Singleton não é usado para quando vc não quer mais que 1. É para quando vc não pode mais que 1.

veja

Estou usando singelton ?
Não.

Estou instanciando mais que um ?
Não.

Queries seria o mesmo que uma fabrica de PessoaQuery, mas como PessoaQuery e' um singleton, ele nao pode ser conciderado fabrica.

............

Quanto ao nome, como disse, o nome pode ser outro, mas o q me atenho aqui sao ha boas praticas...

e gostaria que me disesse onde esta a ma pratica ? e pq eu deveria usar

new PessoaQuery (ou new RepositoryPessoa)
new OutroQuery (ou new RepositoryOutro)

Agora que vc explicou melhor, realmente os seus XXXQuery não na realidade repositorios.E é boa prática chamar as coisas com os nomes certos

nao gosta de fachadas ? paciencia, prefere ter q saber o caminho e o nome de cada Repository ou Query, parabens pra vc, eu prefiro nao ter q me preucupar com isso

Eu não gosto é de ServiceLocator , nem de métodos estáticos, nem de outras coisas que impedem a felxibilidade e testabilidade.
Vc não precisaria do ".queryOn(repository); " se cada objeto XXXQuery tivesse uma referencia a ele. E isso é facil se eles não forem singleton.
E dessa forma vc consegue estar seu dominio com um domainstore em memoria sem usar banco. Muito mais rápido.
Flexibilidade. Testabilidade.

Haa e seguindo o padrao fachada... o acesso aos PessoaQuery sao livres, e vc pode nao utilizar o Queries (que e' apenas o concentrador) e utilizar outro caminho para chegar la

Vamos pensar que uso o seu Queries. eu tenho que o injetar em todas as actions, mesmo quando sei que cada action só manipula uma certa entidade.
Obviamente eu não vou fazer "new Queres ()" dentro de cada action. eu voi injetar esse objeto.
Portanto, injetar isso ou injetar o próprio XXXQuery , qual é a diferença ? Pelos menos agora eu injeto apenas os XXQuery que preciso e não um God Locator

Enfim, o seu esquema é muito melhor do que é comum por ai. Estou apenas dizendo que poderia ser ainda melhor.

This message was edited 1 time. Last update was at 18/03/2010 11:49:11

o Queries e' application scoped, ou seja, injeto ele sem problemas so existe 1 no projeto...

eu quase nunca uso o queryOn(repository) .... tem um outro metodo query() ... so que esse metodo query() apesar de nao precisar do argumento
ele pega o repositorio de uma maneira q so pode ser feita em um app web, ou em um ambiente com threads no mesmo estilo do container web.

pois eu tenho um Interceptador, que guarda a referencia ao repositorio em um ThreadLocal, e resgato ele de la, pois sei, que uma requisicao esta sempre na mesma thread.

nesse ponto eu consigo fazer

List<Pesso> pessoas = queries.forPessoa().listAtivos();

sem usar o queryOn() ....

...................

injetar o queries
new Queries(repo).forPessoa().listAtivos();

ou fazer, queries.forPessoas().listaAtivos().queryOn(repo), pra mim tem o mesmo efeito... e eu axo mais bonito a segunda forma, e mais usavel no meu codigo.

vc fala em injetar o Repo dentro do XQuery, para poder usar em testes.... mas isso seria o mesmo que nao injetar ele, e usar o metodo queryOn(repo)

.................

Eu realmente nao quero mais de 1 instancia, pelo simples fato de nao precisar de mais de 1, por isso fiz o singleton, o construtor do XQuery e' privado, portanto nao ha' como criar ele por ai.

se fosse requerer o repository em sua construcao iria realmente ter q repensar o modelo, e tranformar o Queries em uma fabrica e nao deixar como esta.

Queries.createPessoa(repository).listAtivos();

sergiotaborda wrote:
A JPA é tecnicamente mais limitada que o Hibernate. Ambos têm o mesmo alvo: banco de dados.
Então a unica coisa que faria usar o JPA seria uma independencia maior (que ele não tem) tanto em termos de modelagem, como em termos de execução. Por exemplo, se o JPA não fosse apenas para banco de dados, valeria a pena. Ou se ele fosse realmente agnóstico. Caso contrário o hibernate já provê as mesmas funcionalidades.

Por outro lado o JPA não faz parte do JEE, logo, vc é tão livre de o escolher como escolher o hibernate ou outro qq ORM.

então se o jpa não fosse jpa vc usaria ele? hahhhahahaha

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

bobmoe wrote:

sergiotaborda wrote:
A JPA é tecnicamente mais limitada que o Hibernate. Ambos têm o mesmo alvo: banco de dados.
Então a unica coisa que faria usar o JPA seria uma independencia maior (que ele não tem) tanto em termos de modelagem, como em termos de execução. Por exemplo, se o JPA não fosse apenas para banco de dados, valeria a pena. Ou se ele fosse realmente agnóstico. Caso contrário o hibernate já provê as mesmas funcionalidades.

Por outro lado o JPA não faz parte do JEE, logo, vc é tão livre de o escolher como escolher o hibernate ou outro qq ORM.

então se o jpa não fosse jpa vc usaria ele? hahhhahahaha

Eu não usaria ele a menos que servisse para mais coisas que banco de dados. sim.
É impossível testar um sistema usando JPA sem usar um banco de dados. A Testabilidade do JPA é inexistente. Ao menos com o hibernate dá para encapsular e abstrair a maior parte das coisas.

Se o JPA fosse realmente o Java Persistance API e não o Java ORM API , o mundo seria diferente.

This message was edited 1 time. Last update was at 18/03/2010 13:45:05

sergiotaborda wrote:

bobmoe wrote:

sergiotaborda wrote:
A JPA é tecnicamente mais limitada que o Hibernate. Ambos têm o mesmo alvo: banco de dados.
Então a unica coisa que faria usar o JPA seria uma independencia maior (que ele não tem) tanto em termos de modelagem, como em termos de execução. Por exemplo, se o JPA não fosse apenas para banco de dados, valeria a pena. Ou se ele fosse realmente agnóstico. Caso contrário o hibernate já provê as mesmas funcionalidades.

Por outro lado o JPA não faz parte do JEE, logo, vc é tão livre de o escolher como escolher o hibernate ou outro qq ORM.

então se o jpa não fosse jpa vc usaria ele? hahhhahahaha

Eu não usaria ele a menos que servisse para mais coisas que banco de dados. sim.
É impossível testar um sistema usando JPA sem usar um banco de dados. A Testabilidade do JPA é inexistente. Ao menos com o hibernate dá para encapsular e abstrair a maior parte das coisas.

Se o JPA fosse realmente o Java Persistance API e não o Java ORM API , o mundo seria diferente.

O JCP já tentou, Sérgio, criar uma abstração maior do que banco de dados relacionais através do JDO, mas não funcionou. Justamente pq o mundo corporativo persiste em "banco de dados relacionais", qualquer abstração maior do que ORM seria uma limitação muito grande. O Hibernate brilhou justamente por causa disso... percebendo que não adianta querer abraçar o mundo em todas as formas de persistencia, Gavin focou seu framework na resolução do problema Objeto para Relacional, e foi feliz. O mesmo ocorreu com a especificação. Não acho isso errado, muito pelo contrário, acho prático ...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Alessandro Lazarotti wrote:

sergiotaborda wrote:

bobmoe wrote:

sergiotaborda wrote:
A JPA é tecnicamente mais limitada que o Hibernate. Ambos têm o mesmo alvo: banco de dados.
Então a unica coisa que faria usar o JPA seria uma independencia maior (que ele não tem) tanto em termos de modelagem, como em termos de execução. Por exemplo, se o JPA não fosse apenas para banco de dados, valeria a pena. Ou se ele fosse realmente agnóstico. Caso contrário o hibernate já provê as mesmas funcionalidades.

Por outro lado o JPA não faz parte do JEE, logo, vc é tão livre de o escolher como escolher o hibernate ou outro qq ORM.

então se o jpa não fosse jpa vc usaria ele? hahhhahahaha

Eu não usaria ele a menos que servisse para mais coisas que banco de dados. sim.
É impossível testar um sistema usando JPA sem usar um banco de dados. A Testabilidade do JPA é inexistente. Ao menos com o hibernate dá para encapsular e abstrair a maior parte das coisas.

Se o JPA fosse realmente o Java Persistance API e não o Java ORM API , o mundo seria diferente.

O JCP já tentou, Sérgio, criar uma abstração maior do que banco de dados relacionais através do JDO, mas não funcionou.

Isso não totalmente verdade. O problema do JDO é a falta das pessoas o conhecerem. Veja que o Google App Engine usa JDO.
E tem uma implementação JPA em cima de JDO. E isso porque, lá no GAE não ha banco de dados, ha bigtable.
Mas isso tem um preço. Join não funciona. E não funciona porque é um conceito inerente, ou seja, o JPA não faz join, ele delega o join ao banco de dados. A capacidade de abstrair isso é nula.

Justamente pq o mundo corporativo persiste em "banco de dados relacionais",

Cuidado. Esse conceito persiste nas empresas médias e pequenas, não no mundo corporativo como um todo.
Veja que coisas como o bigTable , o movimento NoSQL e os bancos OO estão ganhando terreno.

qualquer abstração maior do que ORM seria uma limitação muito grande.

Não vejo porque seria uma limitação se fosse bem feito. Repare, eu não estou dizendo que vc deveria ter implementações para todos os tipos de coisa
eu estou dizendo que o framework não deveria limitar isso ha partida. Quer fazer join, blz. Se o implementador suportar isso nativamente otimo, senão a implementação do framework deve simular isso. A principal questão é a falta de capacidade de teste, de fazer mocks, etc.. É o mesmo problema da EJB 2.x que ainda persiste.

Vou-lhe dar um exemplo real. Eu implemento um sistema usando postgress. Ai eu quero colocar a funcionar no GAE. Não posso fazer isso com simples deploy. Não posso fazer isso sequer apenas substituindo o meu DomainStore, porque ele está vinculado ao conceito de banco relacional. Mas eu quero ter esse trabalho de adaptar a aplicação ao GAE? Não. O que que quero é ter componentes intercambiáveis.

E veja, ele até aceita JPA mas não aceita todo o JPA. Ou seja, duh! obriga vc a fazer um monte de coisas na mão.
Isso já para não falar em testabilidade.

O que JPA lhe dá? Aderência à JEE. Apenas e só. Mas ha muito tempo esta adrencia deixou de ser importante para 90% das aplicações.
Para ser importante vc precisa estar correndo aplicações que só podem funcionar em ambiente JEE.

Aderencia à JEE não significa universalidade, como todos sabemos.
Então, amarrado por amarrado é melhor amarrar-se com quem lhe dá mais capacidade e poderes , no caso o hibernate. e não me entenda mal, eu odeio o hibernate e acho que falta concurrencia, contudo dos dois males ele é o menor.

@sergiotarborda

Sergio, mais uma coisa, o meu padrao pode realmente nao ser o padrao repositorio (afinal sua literatura e bem pequena na internete) ...

Pode ser o padrao DomainStore....

Mas uma coisa vc nao tem como negar, o nome esta correto, Repository, o padrao pode ate ser outro, mas chamar o lugar onde se guarda as entidades de Repositorio e' nada alem do obveio, afinal e' isso que e' pra mim.

...............

Pode ser que o padrao nao seja este, mas a nomeclatura esta coerente com o que o objeto tem como responsabilidade, que e' guardar minhas entidades.

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

sergiotaborda wrote:

O problema do JDO é a falta das pessoas o conhecerem. Veja que o Google App Engine usa JDO.
E tem uma implementação JPA em cima de JDO. E isso porque, lá no GAE não ha banco de dados, ha bigtable.
Mas isso tem um preço. Join não funciona. E não funciona porque é um conceito inerente, ou seja, o JPA não faz join, ele delega o join ao banco de dados. A capacidade de abstrair isso é nula.

Não concordo. Durante um bom tempo ele foi conhecido no JavaEE, mas as pessoas deixaram de utilizar justamente porque para as coisas mais simples da persistencia relacional ele era sofrível, e a grande maioria das pessoas utilizavam e ainda utilizam banco relacionais.

sergiotaborda wrote:

Alessandro Lazarotti wrote:
Justamente pq o mundo corporativo persiste em "banco de dados relacionais",

Cuidado. Esse conceito persiste nas empresas médias e pequenas, não no mundo corporativo como um todo.
Veja que coisas como o bigTable , o movimento NoSQL e os bancos OO estão ganhando terreno.

Médias e pequenas? Você esta dizendo que empresas grandes não utilizam banco relacionais? Sergio, isso não é verdade e esta longe de ser. Não acho interessante expor na internet o nome das empresas que ja participei / participo de projetos que utilizam banco de dados relacionais como seu maior repositório de dados. Contudo posso assegurar que as maiores indústrias do ramo automotivo, telecom, petroquímico e químico utilizam banco de dados relacionais... e não são de fato empresas de pequena e médio porte.

sergiotaborda wrote:Vou-lhe dar um exemplo real. Eu implemento um sistema usando postgress. Ai eu quero colocar a funcionar no GAE. Não posso fazer isso com simples deploy. Não posso fazer isso sequer apenas substituindo o meu DomainStore, porque ele está vinculado ao conceito de banco relacional. Mas eu quero ter esse trabalho de adaptar a aplicação ao GAE? Não. O que que quero é ter componentes intercambiáveis.

E veja, ele até aceita JPA mas não aceita todo o JPA. Ou seja, duh! obriga vc a fazer um monte de coisas na mão.
Isso já para não falar em testabilidade.

JPA é O"R"M, ponto final. Se o seu sistema é um dos raros que querem persistir em outro meio que não relacional, não é a tecnologia correta a ser utiliza, não vejo onde esta o pecado nisso. Se você tem uma camada de persistência bem definida, melhor ainda, vc pode optar pela implementação ORM ou qualquer outra coisa, inclusive JDO.

Bom mas como já disse, se vc tem uma idéia de arquitetura diferente da minha, discutiriamos até amanhã sem chegar em um consenso. Simplesmente o que é aceitavel pra mim pode não ser pra vc, e vice-versa.

[]s

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