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

This message was edited 1 time. Last update was at 17/03/2010 13:56:38

mario.fts wrote:Lavieri

poderia explicar melhor esta estrutura:

queries.forPessoa().listPessoasAtivas().queryOn(repository);

pelo que eu entendi queries é uma classe onde vc pode pegar objetos de consulta especificos de cada classe do mdoelo, no caso o forPessoa retorna um desses objetos pra classe Pessoa. nesses objetos estão as queries especificas de pessoas, como no exemplo listPessoasAtivas. só não entendi o que esse query on retorna, acho que é um obejto que sabe qual query a ser executada no repositório, mas não estou com certeza disso.

Achei muito bacana, quero entender pra montar algo do tipo.

[]'s

queries e' uma fachada.... ele conhece os caminhso para os objetos que conhece a query de cada entidade...

PessoaQuery contem todas as querys para pessoas

QueryableList e' uma interface

HiberanteQuery<T> e' uma classe que retorna Queryable<T> ou QueryableList<T>

a implementacao desses metados e' juntar a session do Repository com a DatechedCriteria que e' passado no construtor.

e assim retorna a consulta tipada que esta definida no queryable ou queryablelist

Muito bom cara, vou montar um esquema assim pra testar.

Valeu.

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

rogelgarcia wrote:Com a nova (nem tão nova assim) onda de se utilizar JPA ao invés de Hibernate, surgem as questões...

Quase todo mundo que hoje utiliza JPA, tem como implementação o Hibernate que já utilizavam anteriormente..

O JPA introduziu novas interfaces e classes além do que já tinhamos que saber com o Hibernate. Mas o JPA não é uma especificação completa porque ainda é necessário em alguns momentos utilizar coisas especificas do Hibernate.

O JPA acabou introduzindo uma nova camada de persistencia e nós sabemos que camadas em cima de camadas trazem problemas.

Se a implementação de JPA que todo mundo utiliza é o Hibernate, qual é a utilidade de se ter JPA?

Nenhuma. A utilidade do JPA é nenhuma.
Depois que o pessoal do Core Patterns JEE levou na cabeça , e depois que o Hibernate foi criado foi desenvolvido o padrão DomainStore.
É este padrão que o JPA tenta implementar.
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.

O sucesso do hibernate se deve ao padrão DomainStore e ao fato de ser free. Hoje em dias temos opções como Eclipse Link, mas aprender a usar mais uma ferramenta ORM é chato p'rá caramba.

Usar o JPA é na realidade um erro no contexto geral e só justificavel se vc quiser aderir às normas de portabilidade JEE, que todo o mundo já sabe são falhas em si mesmas.

É um falso argumento que precisamos do JPA para isolar o hibernate. Isso é feito facilmente com objetos criados por nós mesmos usando padrões como bridge e strategy. Eu nunca usaria JPA por escolha.

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

Lavieri wrote:eu iniciei lendo no blog do sergio taborda http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/repository/

depois fui fazendo a minha maneira....

A entender, a diferenca basica do DAO pro RESPOSITORIO, e' que o DAO acumla as queries dentro dele, e por isso vc sai criando 1 DAO por Entidade.... isso traz dificuldade, pois uma Session funciona com um repositorio, ela funciona igual seja a entidade qual for.........

Entao o repositorio tem aceita objetos em seus metodos, e asism repository.add(Object o); e assim para cada operacao,

Tudo que for generico vc deixa no repositorio, ou seja

<T> List<T> repo.list(Class<T> target);
<T> T repo.get(Class<T> target, Object id);
repo.refresh(Object object);

etc etc etc

e as queries as consultas, vc separa coloca em outro objeto, eu crirei uma interface pra fazer isso...

e no fim, eu executo uma Query em um Repository,

que para o hiberante eu so faco pegar um DatechedCriteria que esta dentro do queries, e unir a session dentro do repository, e assim a magica da consulta acontece...

Incrível, mas eu quiz dizer exatamente o contrário do que vc entendeu.
O Repositório não é genérico nem agnóstico, ele é concreto e associado a uma única entidade. O repositório cria as queries, ele não executa as queries.
Cada repositorio especifico contém métodos para encontrar aquele tipo de entidade, conforme critérios que fazem sentido para ela. Pode conter métodos gerais comuns a todas as entidades como save e delete, mas fortemente tipados para aceitar apenas aquele tipo de entidade. nisto os repositorios em nada são diferentes dos antigos DAO.

A diferença entre DAO e Repositório é que o DAO é um tradutor de tecnologias (ORM, OXM, etc...) Repositório é um encapsulador de regras de pesquisas e um ponto centrar para procurar objetos daquela entidade.

vou ter que mehlorar esse artigo

....

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1838 Offline

Alessandro Lazarotti wrote:Tem vários motivos para vc iniciar um projeto com JPA, a maioria já foi explanado aqui, mas vamos lá:

- Bootstrap facilitado: HibernateUtil é um "workaround" necessário para se construir a SessionFactory. Já vi muita implementação meia boca estourando memória por causa disso. O JPA em ambiente JavaEE é bem mais eficiente em sua inicialização com o apoio do persistence.xml, autodiscovery das classes anotadas e gerencia do EntityManager feita automaticamente pelo container (abri, fechar, descarregar e injetar).

- D.I. - Uma vez fazendo parte da especificação, ele se beneficia de todos os demais recursos enterprises, sobre injeção de dependencia e todo seu ciclo de vida. No JavaEE 6, isso esta ainda melhor, uma vez que não apenas EJBs podem se beneficiarem com isso, mas qualquer bean.

- Portabilidade (menos relevante) - nao considero isso a melhor feature para iniciar um projeto com JPA, pq EU utilizao muita coisa do Hibernate. Mas para quem preza por independecia de implementação pode ser um atrativo.

O fato é, 99,9% das vezes inicio os projetos com JPA. Quando algo nao me atende entao getDelegate para obter a session do hibernate, sem pestanejar. Mas nao perco a integração com o ambiente JavaEE e nem seu bootstrap que é uma mao na roda.

Pois então.. tudo isso que voce falou aí .. chegou atrasado.. já existem essas features a 5 anos no framework que eu criei

Pros projetos que eu uso então.. nao teria vantagem.. a nao ser a questao de portabilidade que é o menos importante..

E se eu quiser usar o JPA no desktop.. é trivial?

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1838 Offline

Alessandro Lazarotti wrote:

rogelgarcia wrote:Eu poderia estar com um Mestre desatachado da sessao.. que eu quisesse persistir... (mas a lista de Detalhe está vazia)

Eu gostaria de só alterar o Mestre.. mas se eu pedir pra salvar o Mestre desse jeito.. o hibernate também deleta o detalhe...

Mas "PQ" detalhe esta vazia???
Se Mestre esta detachado e vc faz "Merge", ele nao apaga sua lista, ele relinka os proxies de Detalhe, que NAO esta vazio.
A não ser que vc tenha construído o Mestre com "new", o que nao deveria ser feito.

A parte controller da minha app.. pode ter criado o Mestre.. entao será com new por exemplo

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

Lavieri wrote:j
repository.addAll(carros); repoistory.removeAll(telefones); List<PessoaFisica> pessoasAtivas = queries.forPessoa().listPessoasAtivas().queryOn(repository);

Isto que vc desenhou não é um repositorio é um DAO. Repositorios são usados assim

O codigo não sabe qual é o critério que define que a pessoa é ativa. Nem sabe como procurar essa especie de pessoas

Dentro do Repositorio vc tem isto

Repare que o query é em cima da persistanceStategy. Que pode ser um DAO ou domainStore

O importante aqui é que a criação do critério de busca é no proprio repositório. É essa a sua principal função : encapsular a criação dos critérios.

sergiotaborda wrote:...

O codigo não sabe qual é o critério que define que a pessoa é ativa. Nem sabe como procurar essa especie de pessoas

Dentro do Repositorio vc tem isto

public List<Pessoa> listPessoasAtivas(){ Criteria c = CriteriaBuilder.find(Pessoa.class) with("ativo", true); return persistanceStategy.executeCriteria(c) }

Repare que o query é em cima da persistanceStategy. Que pode ser um DAO ou domainStore

O importante aqui é que a criação do critério de busca é no proprio repositório. É essa a sua principal função : encapsular a criação dos critérios.

Bom o nome pode não ser esse... masss o que eu não gosto do DAO é justamente o fato de ser tipado, e de ter as queries dentro dele, ter que usar 192382938 lugares para adicionar e remover entidades é o ponto onde não gosto.... e pra mim isso é dar um passo pra traz.

O Hiberante aceita qualquer objeto em suas sessions, e vc encapsular a session e restringir isso pra mim é tiro no pé.

.........

O meu repositorio, é realmente o que diz o nome, é um lugar onde se guarda onde se armazena as entidades, é possivel adicionar, remover, atualizar buscar entidades dentro dele.

........

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.

queries.forPessoa().listPessoasAtivas().queryOn(repository);

é apenas pq é muito mais legal 1 repositorio, um único lugar

do que ter

repoPessoa.listPessoasAtivas();
repoCarro.listCarrosByAno(2005);
repoEtc.procureEtcPorCriterioX(x);

enfim isso é xato, é extremamente chato!

repository.forPessoas().listPessoasAtivas(); poderia ate ser... mais ai eu tenho que juntar ao repository, e meu repositorio independe de projeto.

enfim, o conceito que vc viu pode ate ser de ser tudo junto, mas desassociar me da mais flexibilidade, e não tenho intenção de abrir mão disso ^^

This message was edited 2 times. Last update was at 17/03/2010 19:21:35

mario.fts wrote:Muito bom cara, vou montar um esquema assim pra testar.

Valeu.

ahhh

eu também tenho objetos Executables, que é uma interface e tem apenas o método para executar

serve para algo como

This message was edited 2 times. Last update was at 18/03/2010 00:58:41

rogelgarcia wrote:

Alessandro Lazarotti wrote:

rogelgarcia wrote:Eu poderia estar com um Mestre desatachado da sessao.. que eu quisesse persistir... (mas a lista de Detalhe está vazia)

Eu gostaria de só alterar o Mestre.. mas se eu pedir pra salvar o Mestre desse jeito.. o hibernate também deleta o detalhe...

Mas "PQ" detalhe esta vazia???
Se Mestre esta detachado e vc faz "Merge", ele nao apaga sua lista, ele relinka os proxies de Detalhe, que NAO esta vazio.
A não ser que vc tenha construído o Mestre com "new", o que nao deveria ser feito.

A parte controller da minha app.. pode ter criado o Mestre.. entao será com new por exemplo

Será como não, SERA de fato um new. Se o seu controller criou o Mestre, e não buscou do banco, então é um novo Mestre, o detalhe obivamente é vazio e faz sentido que seja - o estado do objeto é transiente. Se você quer ter uma referência ao banco sem ter problema de reescrita em um campo que vc nao esta utilizando, utilize "getReference" em vez de "find". Ele passa seu objeto ao estado persistent, sem carregar nada, nem mesmo ir ao banco, apenas adiciona proxies. Como vc quer apenas setar uma propriedade, essa seria a escolha correta (sem entrar no mérito do batch update).

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

rogelgarcia wrote:
Pois então.. tudo isso que voce falou aí .. chegou atrasado.. já existem essas features a 5 anos no framework que eu criei

Pros projetos que eu uso então.. nao teria vantagem.. a nao ser a questao de portabilidade que é o menos importante..

E se eu quiser usar o JPA no desktop.. é trivial?

Então seu framework chegou atrasado, estas features já existiam a muito mais tempo na integração do Spring com HIbernate, por exemplo. Mas sua pergunta não foi essa, e sim - "Qual a importancia de se utilizar JPA ao invés de Hibernate?" - não somado a utilização de outros framework.

Utilizar JPA em Desktop tem os mesmos problemas de utilizar Hibernate em Desktop. Com a vantagem de você poder utilizar o Persistence.createEntityManagerFactory("blablabla") em vez de implementar o HibernateUtil.

This message was edited 1 time. Last update was at 18/03/2010 00:57:52

Embora discorde dos pontos que vc colocou, Taborda, como justificativa a NUNCA usar JPA, eu respeito. Faço isso por conhecer e ter trabalhado com pessoas que tem a mesma visão que a sua. Na minha opinião é uma decisão de arquitetura, tem gente que gosta, tem gente que não.

Mas gostaria realmente de enteder alguns destes pontos que vc colocou. Por exemplo:

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? Na verdade o próprio Hibernate tbm tem suporte a queries nativas através de session.createSQLQuery, exatamente da mesma forma que entityManager.nativeQuery. Assim como no hibernate, utiliza querys nativas quem quer por própria conta e risco, ou pode usar JPQL ou Criteria com a APi da especificação, como vc usa HQL com o HIbernate Core.

Lavieri wrote:

mario.fts wrote:Lavieri

poderia explicar melhor esta estrutura:

queries.forPessoa().listPessoasAtivas().queryOn(repository);

pelo que eu entendi queries é uma classe onde vc pode pegar objetos de consulta especificos de cada classe do mdoelo, no caso o forPessoa retorna um desses objetos pra classe Pessoa. nesses objetos estão as queries especificas de pessoas, como no exemplo listPessoasAtivas. só não entendi o que esse query on retorna, acho que é um obejto que sabe qual query a ser executada no repositório, mas não estou com certeza disso.

Achei muito bacana, quero entender pra montar algo do tipo.

[]'s

queries e' uma fachada.... ele conhece os caminhso para os objetos que conhece a query de cada entidade...
public class Queries { public PessoaQuery forPessoa() { return PessoaQuery.getInstance(); } public ImovelQuery forImovel() { return ImovelQuery.getInstance(); } } //ou seja apenas uma facahada.....

PessoaQuery contem todas as querys para pessoas

public class PessoaQuery { public QueryableList<Pessoa> listarAtivas() { DatechedCriteria dc = DatechedCriteria.forClass(Pessoa.class) .add(Restrictions.eq("ativo",true); return new HibernateQuery<Pessoa>(dc).list(); } public Queryable<Pessoa> byCpf(String cpf) { //... return new HibernateQuery<Pessoa>(dc).unique(); } }

QueryableList e' uma interface

public Queryable<T> { T queryOn(Repository rep); } public QueryableList<T> extends Queryable<List<T>> { List<T> queryOn(Repository rep,int startPosition); List<T> queryOn(Repository rep,int startPosition,int maxResults); }

HiberanteQuery<T> e' uma classe que retorna Queryable<T> ou QueryableList<T>

public HiberanteQuery<T> { public HiberanteQuery<T>(DetachedCriteria dc) {this.dc = dc} Queryable<T> unique(); Queryable<T> first(); Queryable<Integer> count(); QueryableList<T> list(); }

a implementacao desses metados e' juntar a session do Repository com a DatechedCriteria que e' passado no construtor.

e assim retorna a consulta tipada que esta definida no queryable ou queryablelist

Quanta complicação.

Qual o objetivo disto tudo?
Crie um Repository (Interface sobre uma DAO ou como uma classe Concreta) e seja feliz!

Alexandro.Almeida wrote:
Quanta complicação. Qual o objetivo disto tudo?
Crie um Repository (Interface sobre uma DAO ou como uma classe Concreta) e seja feliz!

eu sou feliz, vc nao ?

o objetivo e' tornar o codigo claro, legivel, e separar a camada de persistencia do restante do projeto.

nao pense que fico la escrevendo o queries o tempo todo, e que la tem consultas q eu nao preciso por exemplo...

o processo e' simples

queries.forPessoas().listPessoasAtivas()

nesse ponto eu aperto CTRL + 1 ... no eclipse, ele cria o metodo na classe, eu escrevo o DetachedCriteria rapidinho e pronto, volto pra logica

depois sempre que precisa fica la no mesmo canto a consulta....

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

eu trabalho em varios projetos ao mesmo tempo, todos com o mesmo pacote basico, e com a mesma estrutura .... trabalhar em um com centanas de dao, pode ser bom, mas quando trabalhe com varios e' so ter 2 objetos para camada de persistencia (o Repositorio e o Queries) e' simplismente otimo

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

Lavieri wrote:

Bom o nome pode não ser esse... masss o que eu não gosto do DAO é justamente o fato de ser tipado, e de ter as queries dentro dele, ter que usar 192382938 lugares para adicionar e remover entidades é o ponto onde não gosto.... e pra mim isso é dar um passo pra traz.

O Hiberante aceita qualquer objeto em suas sessions, e vc encapsular a session e restringir isso pra mim é tiro no pé.

.........

O meu repositorio, é realmente o que diz o nome, é um lugar onde se guarda onde se armazena as entidades, é possivel adicionar, remover, atualizar buscar entidades dentro dele.

........

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.

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.

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