Hibernate é ralmente necessario ou a melhor opção?

Bom, se você só usa queries nativas e não faz mapeamento objeto relacional, então é capaz que não haja motivo para usar o Hibernate mesmo. Minha única sugestão é que você mantenha o resto da aplicação alheia ao mecanismo de persistência.

Você poderia fazer na unha por JDBC sem problema.

Existem outras bibliotecas de JPA que tem menos depedências, a Batoo por exemplo, já teve testes de perfomance de até 15x melhor. [=

Hibernate tem um mundo de funções e vantagens que em geral não são utilizadas. [=

A vantagem é o ganho em desenvolvimento, a questão da perfomance… creio que pesaria em uma aplicações milhares de acessos e linhas no db. [=

Hebert Coelho:

Você poderia fazer na unha por JDBC sem problema.

Existem outras bibliotecas de JPA que tem menos depedências, a Batoo por exemplo, já teve testes de perfomance de até 15x melhor. [=

Hibernate tem um mundo de funções e vantagens que em geral não são utilizadas. [=

A vantagem é o ganho em desenvolvimento, a questão da perfomance… creio que pesaria em uma aplicações milhares de acessos e linhas no db. [=

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

renatomattos2912:

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

Existem diversas técnicas de otimização que podem ser utilizadas, mas ainda assim em certos casos (coisas específicas) o jdbc é o indicado.

Hebert Coelho:

renatomattos2912:

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

Mas quando digo muitos, é muito mesmo. [=

Existem diversas técnicas de otimização que podem ser utilizadas, mas ainda assim em certos casos (coisas específicas) o jdbc é o indicado.

Entendi, bom vc acha q vale a pena eu arriscar com o batoo?? ja estou criando um projeto paralelo pra estudar ele de qualquer forma

Para criação de Batches, o hibernate não é muito indicado, preferindo-se mesmo acesso direto via jdbc.

renatomattos2912:

Entendi, bom vc acha q vale a pena eu arriscar com o batoo?? ja estou criando um projeto paralelo pra estudar ele de qualquer forma

Caso sua aplicação seja toda anotada com JPA, para mudar de Batto para ElipseLink ou Hibernate, basta trocar o jar e o provider. [=

Hebert Coelho:

renatomattos2912:

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

Mas quando digo muitos, é muito mesmo. [=

Existem diversas técnicas de otimização que podem ser utilizadas, mas ainda assim em certos casos (coisas específicas) o jdbc é o indicado.

Assim, não dá pra dizer que você vai obter mais performance pelo simples fato de usar JDBC ou Hibernate ou o Baddo. O fato de que o site terá muitos acessos também não quer dizer muita coisa (pode ser que em 90% das requisições a aplicação não vá ao banco). Ou seja, você precisa analisar o problema antes. Vamos lá:

A questão Hibernate x JDBC é parecida com a questão Java x C++. De fato, é possível economizar recursos em termos de CPU e memória com o JDBC. Mas isso não quer dizer que seja fácil e nem sempre CPU e memória são gargalos. Geralmente, quando se trata de uma aplicação voltada ao usuário as preocupações de fato são: responsividade (o quão rápido a aplicação processa um requisição) e a escalabilidade (o quanto a aplicação suporta o crescimento). Nesses casos, os maiores gargalos estão relacionados a número de acessos ao banco de dados, tempo de duração das transações. etc. O Hibernate já faz um bom trabalho com relação a esses quesitos com recursos como o cache, execução tardia de DDL, etc.

É o mesmo caso da comparação entre o Hibernate e o Batto. Eu dei uma lida rápida em alguns sites, e até onde eu vi, o Batoo ganha do Hibernate em termos de CPU, que dificilmente é o gargalo no acesso ao banco de dados.

Por fim, nada te impede de usar mais de uma solução de persistência. Você pode usar o Hibernate para os casos gerais e o JDBC para os casos em que você precisa de um fine-tunning. Você só não pode tomar essa decisão de maneira “cega”.

rmendes08:

Hebert Coelho:

renatomattos2912:

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

Mas quando digo muitos, é muito mesmo. [=

Existem diversas técnicas de otimização que podem ser utilizadas, mas ainda assim em certos casos (coisas específicas) o jdbc é o indicado.

Assim, não dá pra dizer que você vai obter mais performance pelo simples fato de usar JDBC ou Hibernate ou o Baddo. O fato de que o site terá muitos acessos também não quer dizer muita coisa (pode ser que em 90% das requisições a aplicação não vá ao banco). Ou seja, você precisa analisar o problema antes. Vamos lá:

A questão Hibernate x JDBC é parecida com a questão Java x C++. De fato, é possível economizar recursos em termos de CPU e memória com o JDBC. Mas isso não quer dizer que seja fácil e nem sempre CPU e memória são gargalos. Geralmente, quando se trata de uma aplicação voltada ao usuário as preocupações de fato são: responsividade (o quão rápido a aplicação processa um requisição) e a escalabilidade (o quanto a aplicação suporta o crescimento). Nesses casos, os maiores gargalos estão relacionados a número de acessos ao banco de dados, tempo de duração das transações. etc. O Hibernate já faz um bom trabalho com relação a esses quesitos com recursos como o cache, execução tardia de DDL, etc.

É o mesmo caso da comparação entre o Hibernate e o Batto. Eu dei uma lida rápida em alguns sites, e até onde eu vi, o Batoo ganha do Hibernate em termos de CPU, que dificilmente é o gargalo no acesso ao banco de dados.

Por fim, nada te impede de usar mais de uma solução de persistência. Você pode usar o Hibernate para os casos gerais e o JDBC para os casos em que você precisa de um fine-tunning. Você só não pode tomar essa decisão de maneira “cega”.

Entendi, muito obrigado

rmendes08:

Hebert Coelho:

renatomattos2912:

A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo

Mas quando digo muitos, é muito mesmo. [=

Existem diversas técnicas de otimização que podem ser utilizadas, mas ainda assim em certos casos (coisas específicas) o jdbc é o indicado.

Assim, não dá pra dizer que você vai obter mais performance pelo simples fato de usar JDBC ou Hibernate ou o Baddo. O fato de que o site terá muitos acessos também não quer dizer muita coisa (pode ser que em 90% das requisições a aplicação não vá ao banco). Ou seja, você precisa analisar o problema antes. Vamos lá:

A questão Hibernate x JDBC é parecida com a questão Java x C++. De fato, é possível economizar recursos em termos de CPU e memória com o JDBC. Mas isso não quer dizer que seja fácil e nem sempre CPU e memória são gargalos. Geralmente, quando se trata de uma aplicação voltada ao usuário as preocupações de fato são: responsividade (o quão rápido a aplicação processa um requisição) e a escalabilidade (o quanto a aplicação suporta o crescimento). Nesses casos, os maiores gargalos estão relacionados a número de acessos ao banco de dados, tempo de duração das transações. etc. O Hibernate já faz um bom trabalho com relação a esses quesitos com recursos como o cache, execução tardia de DDL, etc.

É o mesmo caso da comparação entre o Hibernate e o Batto. Eu dei uma lida rápida em alguns sites, e até onde eu vi, o Batoo ganha do Hibernate em termos de CPU, que dificilmente é o gargalo no acesso ao banco de dados.

Por fim, nada te impede de usar mais de uma solução de persistência. Você pode usar o Hibernate para os casos gerais e o JDBC para os casos em que você precisa de um fine-tunning. Você só não pode tomar essa decisão de maneira “cega”.

Geralmente usar hibernate não é problema, o problema é se não lidar adequadamente com cada tipo de caso, uso correto de lazy ou não é só o início. Uma coisa que é básica pra mim, em relatórios e consultas complexas prefira usar SQL nativo (named query no hibernate) ou se preferir ‘Criteria’ anule os lazys e aplique fetch joins como saídas performáticas usando as entidades, mas Criterias extensas demais podem ser complicadas para entender depois de um tempo sem ver, então escrever SQL é mais natural para esses casos de relatórios e consultas complexas, não sou purista mesmo. Fora isso, cadastros administrativos tranquilo usar os recursos normais no modelo de entidades, e telas mais voltadas a processos de negócio usar também normalmente, mas em pontos que forem críticos, avaliar necessidade de uso de SQL direto.

Tem que usar cada coisa que for te ajudar e não atrapalhar. E outra coisa que vejo muito é ficar se limitando a SQL ANSI sem necessidade, uma grande empresa que use por exemplo o Oracle não vai mudar de banco tão cedo. É tudo questão do caso como já falaram, então especifique melhor o seu.

Hibernate = Lixo (na minha opinião)

http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

saoj:

Hibernate = Lixo (na minha opinião)

http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

Tenta esse: http://mentabean.soliveirajr.com

Respeito quem nao gosta do Hibernate tem suas razoes assim como eu nao gosto de JSF. Para quem gosta e ainda nao conhece aqui tem um texto interessante da caelum com resumo das possibilidades para bom uso do Hibernate, considerem o que for positivo pra voces em cada caso: http://blog.caelum.com.br/os-7-habitos-dos-desenvolvedores-hibernate-e-jpa-altamente-eficazes/

javaflex:

Respeito quem nao gosta do Hibernate tem suas razoes assim como eu nao gosto de JSF. Para quem gosta e ainda nao conhece aqui tem um texto interessante da caelum com resumo das possibilidades para bom uso do Hibernate, considerem o que for positivo pra voces em cada caso: http://blog.caelum.com.br/os-7-habitos-dos-desenvolvedores-hibernate-e-jpa-altamente-eficazes/

Acho triste isso.

Já vi diversas pessoas criticando frameworks e quando eu pergunto pq elas dão motivos que não são verdadeiros… triste viu! -_-’’

Hebert Coelho:

javaflex:

Respeito quem nao gosta do Hibernate tem suas razoes assim como eu nao gosto de JSF. Para quem gosta e ainda nao conhece aqui tem um texto interessante da caelum com resumo das possibilidades para bom uso do Hibernate, considerem o que for positivo pra voces em cada caso: http://blog.caelum.com.br/os-7-habitos-dos-desenvolvedores-hibernate-e-jpa-altamente-eficazes/

Pois é. O problema é que pessoas começam usar o Hibernate sem ao menos saber o que é JPA. Aí fica presa a um Framework, fazem código de péssima qualidade e depois acabam por culpar o framework…

Acho triste isso.

Já vi diversas pessoas criticando frameworks e quando eu pergunto pq elas dão motivos que não são verdadeiros… triste viu! -_-’’

Eu dei um monte de motivos aqui.

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

Claro que haverá sempre controvérsias e opiniões contrárias, mas acredito que minha opinião pessoal está bem elaborada.

Vc pode concordar ou descordar, mas pelo menos ela é uma opinião bem embasada e não apenas um maluco marretando alguma coisa.

Minha opinião é que o Hibernate fugiu do controle há muito tempo. Está pesado, complexo e obsoleto. Outras opções melhores evoluiram por fora.

ActiveRecord
iBatis
MentaBeans
jOOQ

e outras…

Eu não gosto nem de hibernate nem de JPA. E acredito que esses projetos são muito enganação do que qualquer outra coisa. Se você acha ruim JDBC na mão, que tal experimentar o MyBatis? Acho uma alternativa muito mais viável que hiba/jpa, fora que você tem mais controle do que faz e é mais rápido, mesmo sendo mais “verboso”.

P.S.: Alias… estou adorando estudar bancos NoSQL como MongoDB, usando com o Node.JS

Hebert Coelho:

saoj:

Hibernate = Lixo (na minha opinião)

http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

Por isso que sempre indico o EclipseLink ou o Batto (apesar de não ter testado). [=

Bom, mas pela argumentação do saoj, trocar o Hibernate por outra solução JPA seria trocar 6 por 1/2 dúzia …

rmendes08:

Hebert Coelho:

saoj:

Hibernate = Lixo (na minha opinião)

http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

Por isso que sempre indico o EclipseLink ou o Batto (apesar de não ter testado). [=

Bom, mas pela argumentação do saoj, trocar o Hibernate por outra solução JPA seria trocar 6 por 1/2 dúzia …

Grinvon:

P.S.: Alias… estou adorando estudar bancos NoSQL como MongoDB, usando com o Node.JS

até onde eu trabalhei, seria impossível alterar toda a estrutura de DB.

Hebert Coelho:

rmendes08:

Hebert Coelho:

saoj:

Hibernate = Lixo (na minha opinião)

http://www.guj.com.br/java/252013-voce-nao-gosta-do-hibernate-eu-tb-nao-leia-para-entender-o-porque

http://mentablog.soliveirajr.com/2012/11/hibernate-is-more-complex-than-the-problem-it-tries-to-solve/

Por isso que sempre indico o EclipseLink ou o Batto (apesar de não ter testado). [=

Bom, mas pela argumentação do saoj, trocar o Hibernate por outra solução JPA seria trocar 6 por 1/2 dúzia …

Até então ele atacou especificamente apenas hibernate… :lol: :lol: :lol:

Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.

rmendes08:

Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.

Eu costumo olhar vagas que recebo no email e o que mais vejo é JPA, JDBC e Spring com Mybatis as vezes.

Bem. Infelizmente não existe uma solução perfeita (ainda), enquanto essa solução não chega, eu continuo indo atrás da que me trará mais oportunidade no mercado. [=

Hebert Coelho:

rmendes08:

Sim, mas qualquer implementação JPA tem as deficiências que o saoj apontou no artigo: você ainda precisa aprenderá uma nova linguagem de query (JPQL), a curva de aprendizado de JPA também é alta, o mapeamento precisa ser feito por anotações e XML, e o programador também não controle sobre quais comandos são executados e quando.

Sim, concordo e discordo mas deixa pra lá.
Eu olho o que está em evidência no mercado. O que indicaria então?

Eu costumo olhar vagas que recebo no email e o que mais vejo é JPA, JDBC e Spring com Mybatis as vezes.

Bem. Infelizmente não existe uma solução perfeita (ainda), enquanto essa solução não chega, eu continuo indo atrás da que me trará mais oportunidade no mercado. [=

É a velha história, pra dizer se uma ferramente é boa ou ruim depende do contexto, do problema.

Em tempo, eu não tenho nada contra Hibernate ou JPA, mas eu acho os questionamentos do saoj muito válidos. De fato, o framework/especificação traz toda uma complexidade e é preciso colocar na balança se essa complexidade vai compensar em termos de produtividade, é a velha história de querer matar formiga com bazuca.

Agora, para escolher entre as implementações do JPA, eu acho que a melhor opção é usar a implementação que acompanha seu servidor de aplicação. Mas e se for Tomcat ou Jetty ? Nesse caso, talvez seja um indicativo de que um ORM mais simples dará conta do recado.

rmendes08:

É a velha história, pra dizer se uma ferramente é boa ou ruim depende do contexto, do problema.

Em tempo, eu não tenho nada contra Hibernate ou JPA, mas eu acho os questionamentos do saoj muito válidos. De fato, o framework/especificação traz toda uma complexidade e é preciso colocar na balança se essa complexidade vai compensar em termos de produtividade, é a velha história de querer matar formiga com bazuca.

Agora, para escolher entre as implementações do JPA, eu acho que a melhor opção é usar a implementação que acompanha seu servidor de aplicação. Mas e se for Tomcat ou Jetty ? Nesse caso, talvez seja um indicativo de que um ORM mais simples dará conta do recado.

Até o próprio java é a coisa mais fácil de criticar…

Mas quem disse que o mercado entende das coisas? Olha o passado e vc verá que as ditas soluções padrões do mercado são hoje motivo de chacota.

Se lembra do Struts1 que todo mundo usava? Se lembra do EJB1 que era a grande revolução? Se lembra daquele mundo de XML para configurar qualquer coisa? Até eu achei interessante a primeira vez que eu vi, pois XML era o buzzword mais quente daquela época.

Não estamos discutindo aqui o que vai aumentar a sua empregabilidade no mercado, mas sim o que é mais recomendável e vantajoso para um projeto.

Claro, nada é perfeito. Não é questão de ser melhor ou pior. É uma questão de escolher a FILOSOFIA. O hibernate (e o JPA) não é legal e vão por um caminho equivocado gerando muita complexidade, peso e dores-de-cabeça no longo prazo. Minha opinião.

saoj:

Mas quem disse que o mercado entende das coisas? Olha o passado e vc verá que as ditas soluções padrões do mercado são hoje motivo de chacota.

Se lembra do Struts1 que todo mundo usava? Se lembra do EJB1 que era a grande revolução? Se lembra daquele mundo de XML para configurar qualquer coisa? Até eu achei interessante a primeira vez que eu vi, pois XML era o buzzword mais quente daquela época.

Não estamos discutindo aqui o que vai aumentar a sua empregabilidade no mercado, mas sim o que é mais recomendável e vantajoso para um projeto.

Claro, nada é perfeito. Não é questão de ser melhor ou pior. É uma questão de escolher a FILOSOFIA. O hibernate (e o JPA) não é legal e vão por um caminho equivocado gerando muita complexidade, peso e dores-de-cabeça no longo prazo. Minha opinião.

Existem frameworks sendo utilizados onde nem livros são encontrados para estudar…

Bem, mas pelo visto estou desvirtuando o tema do tópico.

Voltando, eu indico o JPA/Hibernate seja lá o que for sim. [=

Concordo que isso é uma vantagem. Mas se vc colocar as vantagens e desvantagens na balança vai ver que essa vantagem que vc citou não paga as inúmeras desvantagens do Hibernate.

E é nesse momento que entra a importância fundamental da simplicidade: vc não treina um cara em hibernate em menos de 6 meses. Mas vc treina um cara em MentaBean em menos de 6 dias.

Vc pode contratar um cara que não sabe MentaBean mas sabe um pouco (ou nada) JDBC e bastante SQL, e ele vai estar up-to-speed em 6 dias com o MentaBean.

Agora contrata um cara que sabe bastante de JDBC e SQL e manda ele assumir um hibernate sem experiência com o Hibernate.

O Hibernate é uma complexidade absurda… transforma o seu sistema numa zona imprevisível. Minha opinião.

saoj:

Hebert Coelho:

Eu vejo que vantagem para um projeto também é usar um framework onde seja mais fácil encontrar funcionários e um farto material para estudar.

Existem frameworks sendo utilizados onde nem livros são encontrados para estudar…

Concordo que isso é uma vantagem. Mas se vc colocar as vantagens e desvantagens na balança vai ver que essa vantagem que vc citou não paga as inúmeras desvantagens do Hibernate.

E é nesse momento que entra a importância fundamental da simplicidade: vc não treina um cara em hibernate em menos de 6 meses. Mas vc treina um cara em MentaBean em menos de 6 dias.

Vc pode contratar um cara que não sabe MentaBean mas sabe um pouco (ou nada) JDBC e bastante SQL, e ele vai estar up-to-speed em 6 dias com o MentaBean.

Agora contrata um cara que sabe bastante de JDBC e SQL e manda ele assumir um hibernate sem experiência com o Hibernate.

O Hibernate é uma complexidade absurda… transforma o seu sistema numa zona imprevisível. Minha opinião.

OBS.: Falo de faculdade pois sou professor. [=

Uma opinião minha: Não seria melhor ensinar os estudantes de banco-de-dados sobre índices, SQL, sharding, joins, transactions, caching, lazy/eager loading, locking, isolation levels, etc. ???

O hibernate tenta abstrair isso com efeitos catastróficos. É mais ou menos como um MAKER da vida. Te permite fazer tudo sem saber nada. Recipe for disaster!

Foi falado que o iBatis é uma boa solução.

Discordo completamente… iBatis é algo que só serve para select e mais nada.
É um tiro no pé colocar algo tão rudimentar da idade da pedra num projeto grande.

Faço manutenção num sistema grande que usa o Ibatis e ele te limita muito, fora que a documentação
é fraquissima.

saoj:

Uma opinião minha: Não seria melhor ensinar os estudantes de banco-de-dados sobre índices, SQL, sharding, joins, transactions, caching, lazy/eager loading, locking, isolation levels, etc. ???

O hibernate tenta abstrair isso com efeitos catastróficos. É mais ou menos como um MAKER da vida. Te permite fazer tudo sem saber nada. Recipe for disaster!

Bem é opinião né? [=

O que eu acho ruim no hibernate/JPA é a intrusão no código… Como utilizá-lo em um sistema legado ou para interagir com um?
É difícil trabalhar de forma “híbrida” com ele… Ou seja, quero usá-lo para um módulo novo, mas preciso manter o que está hoje sem alterações… Não vejo uma forma “amigável” de fazer isso com hibernate…

E outra, já vi vários tópicos do tipo:

E eu me pergunto… O cara tem a solução na mão (a própria SQL), mas deve traduzir isso para que o framework entenda? :shock:

embaçado…

erico_kl:

O que eu acho ruim no hibernate/JPA é a intrusão no código… Como utilizá-lo em um sistema legado ou para interagir com um?
É difícil trabalhar de forma “híbrida” com ele… Ou seja, quero usá-lo para um módulo novo, mas preciso manter o que está hoje sem alterações… Não vejo uma forma “amigável” de fazer isso com hibernate…

E outra, já vi vários tópicos do tipo:

E eu me pergunto… O cara tem a solução na mão (a própria SQL), mas deve traduzir isso para que o framework entenda? :shock:

embaçado…

1. JPA dá suporte a bancos já existentes… Não precisa ser um DB legal.
2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.
3. O mapeamento pode ser feito em xml para que o código não seja intrusivo…

Nem sempre a decisão da equipe vai ser pelo que for melhor tecnicamente, vários outros fatores podem pesar mais como já falado por aqui, como o fator mercado, isso de fato pesa.

Hibernate se torna problema dependendo do uso, ele não tem só canhão, tem armas leves também. Na equipe que trabalho lidamos com cada tipo de situação, aplicando o recurso mais adequado dentro do Hibernate, seja ele “normal”, stateless ou uso de SQL nativo mapeado. Essas são as principais possibilidades que devem ser exploradas e não só ficar no uso do hibernate de forma padrão para todos os casos.

Achei ótimo alguns itens que escreveu e respeito as demais críticas. Concordo que o Hibernate do Java ainda é muito tosco na parte de mapeamento, onde é feito com gambiarra (amarrado com annotations) ou o velho XML. E a linguagem de consulta de objetos fica ilegível em situações complexas e stringada demais nas propriedades, onde é melhor usar SQL mesmo. Mas ao mesmo tempo não entendo por que o povo do Java não copia as melhorias feitas no NHibernate, como mapeamento programático e QueryOver.

Sobre tanto falar para usar SQL ao invés de consulta em objetos, você mesmo sabe que isso é opcional no hibernate, então cada time entra em consenso do que vai ajudar mais num projeto ou situação.

Sei que tem empresas ainda que aplicam a ditadura do purismo, mas fujam disso.

Aí vem aquela velha história… Realmente preciso me preocupar com mudança de banco no meio do projeto? Isso vai ser algo tão trivial assim? Se sim, somente com JPA terei suporte a diferentes dialetos?
As duas primeiras perguntas somente o contexto do meu projeto que vai responder.

Certo, só aí não consigo ver a vantagem do framework.

E aí vc perde o refactoring…

erico_kl:

Hebert Coelho:

2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.

Certo, só aí não consigo ver a vantagem do framework…

javaflex:

erico_kl:

Hebert Coelho:

2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.

Certo, só aí não consigo ver a vantagem do framework…

A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.

erico_kl:

javaflex:

erico_kl:

Hebert Coelho:

2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.

Certo, só aí não consigo ver a vantagem do framework…

A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.

Eu não me referia à vantagem de usar SQL pura, mas sim a vantagem de usar SQL pura com o Hibernate. Quando se faz isso vc consegue aproveitar todo o mepamento já criado?

Tem suas limitações, mas existe o Transformers:

Aí vem aquela velha história… Realmente preciso me preocupar com mudança de banco no meio do projeto? Isso vai ser algo tão trivial assim? Se sim, somente com JPA terei suporte a diferentes dialetos?
As duas primeiras perguntas somente o contexto do meu projeto que vai responder.

Certo, só aí não consigo ver a vantagem do framework.

E aí vc perde o refactoring…

1. Sim, com JPA você terá suporte a diferentes dialetos. Já trabalhei em aplicações que rodavam em 4 bancos diferentes, todas usando a mesma JPQL.
2. Uma vantagem é produtividade. Imagine uma query que traga uma classe com 40 campos e dois relacionamentos com 20 campos cada… Haja animo para montar o resultado dessa query do JDBC… get/set para cada campo, loops e assim vai. JPA você pode criar um objeto só para uma query de relatório e apontar para uma classe pronto. Outra vantagem é que você pode usar da vantagem nativa do banco de dados, alguma função específica. A maioria das aplicações rodam em cima de um banco apenas que eu já trabalhei, então pra que se preocupar em portabilidade? Usa a NativeQuery se esse é o problema…
3. Não entendi, como assim perde o refactoring?

erico_kl:

javaflex:

erico_kl:

Hebert Coelho:

2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.

Certo, só aí não consigo ver a vantagem do framework…

A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.

Eu não me referia à vantagem de usar SQL pura, mas sim a vantagem de usar SQL pura com o Hibernate. Quando se faz isso vc consegue aproveitar todo o mepamento já criado?

Só não entendi sobre “aproveitar mapeamento já criado”, mas me refiro com algo já planejado em que você cria uma classe enxuta dedicada a query do relatório.

Exemplo qualquer:

<sql-query name="QueryResultadoVenda"> <return class="pacote.ResultadoVenda"/> <![CDATA[ select rownum as id, campo1, campo2 from tabela where campo3 = :parametro ]]> </sql-query> Então para cada tipo de problema use a arma adequada dentro do próprio framework.

Não duvidei do suporte à diferentes dialetos, na verdade acho isso algo bem interessante. O que quis levantar foi: SOMENTE com JPA que terei suporte à outros bancos? E a resposta é: Não.

Este ganho na produtividade existe em outros frameworks também, e nem por isso precisam fazer “mágica” pra isso. O exemplo que mais posso argumentar é o caso do MentaBean… Você monta a sql como quiser e nem por isso precisa percorrer o ResultSet manualmente para formar a lista de retorno, não importa o quão complexa seja a query.

O xml não fica “preso ao fonte”. Como a configuração não é programática, a cada alteração na sua camada de negócios (inclusão, alteração ou remoção de alguma propriedade), você deve catar a respectiva configuração no xml e alterar lá também. Ou seja, vc perde uma grande vantagem: refatoração.

javaflex:

erico_kl:

javaflex:

erico_kl:

Hebert Coelho:

2. Pode-se executar as queries prontas, sem problema algum, não é preciso traduzir todas as queries para JPQL.

Certo, só aí não consigo ver a vantagem do framework…

A vantagem é ter a possibilidade de usar SQL em situacoes especiais, como relatorios. Isso nao vai tirar as vantagens dos principais recursos do hibernate para situacoes rotineiras de SQL.

Eu não me referia à vantagem de usar SQL pura, mas sim a vantagem de usar SQL pura com o Hibernate. Quando se faz isso vc consegue aproveitar todo o mepamento já criado?

Falai cara. É exatamente sobre usar SQL pura com Hibernate que eu quis dizer, nada fora dele. Seria named query nativa por exemplo e também o Transformer como o Arthur F. Ferreira falou (funciona bem nos casos mais comuns, só é necessário na classe seguir corretamente o tipo de cada propriedade em relação ao que o banco vai trazer, pois ele faz o mapeamento automaticamente). Então opções não faltam.

Só não entendi sobre “aproveitar mapeamento já criado”, mas me refiro com algo já planejado em que você cria uma classe enxuta dedicada a query do relatório.

Exemplo qualquer:

<sql-query name="QueryResultadoVenda"> <return class="pacote.ResultadoVenda"/> <![CDATA[ select rownum as id, campo1, campo2 from tabela where campo3 = :parametro ]]> </sql-query> Então para cada tipo de problema use a arma adequada dentro do próprio framework.

Me corrija se eu estiver errado, você fala de Named Queries, aquelas sqls que podem ficar tanto no XML como na sua classe de negócios?

Se usando sql nativa no hibernate você constrói a sql da maneira que quiser (em tempo de execução) e pega os dados a partir do mapeamento criado (no xml ou via annotation).

Sim, no XML ou via código através de createSQLQuery + Transformer num Repositorio específico. Na classe de negócios você diz entidade com aqueles mapeamentos por annotations? Eu particularmente não gosto, por além de amarrar outros recursos e misturar as coisas, é confuso demais de ver, gosto de olhar a entidade puramente, assim é mais fácil de entender o negócio. Mas se uma equipe decidir que vai ser mais prático assim e teve experiencia de sucesso, então que se respeite.

Uma coisa vocês tem razao, Hibernate (do Java) parou no tempo, sentou no sucesso, tá na hora de acordar e ter mapeamento programático, pois no NHibernate do .NET é tudo perfeito nesse aspecto, por isso eu gosto tanto e seria muito bom ter isso no Java também.

Por fim, seja lá qual for opção, vai poder usar SQL do jeito que quiser mesmo, e o resultado será automaticamente populado em uma lista de uma classe, ou um valor direto no caso de query scalar.

Desde o início que eu vi que não prestava. Minha principal crítica é a falta total de controle que vc tem em cima do framework.

Why the Hibernate learning curve is so big? Why does Hibernate do so many things automagically that I cannot control or understand?

When I check the Java questions in a forum or discussion list I can?t help but notice that a lot of them are about Hibernate. Hibernate can have some qualities but ?persistency that just works? is not one of them. It often does not work or works in ways you could have never imagined. I must agree with what Pascal Thivent says here: ?Hibernate in the wrong hands can be a real disaster!?. Below I list another examples of Hibernate surprising behaviors:

Do people really think that without Hibernate you have to write a lot of SQL and JDBC boilerplate?
People who think like that were probably so busy learning Hibernate that they missed the alternative movement of query builders or worse, don?t understand the wonders that reflection, proxies and abstraction can do to simplify things. Check the code below which performs a SQL query:

Connection conn = getConnection();
BeanSession session = getBeanSession(conn);
 
PreparedStatement stmt = null;
ResultSet rset = null;
 
try {
 
    StringBuilder sql = new StringBuilder(1024);
    sql.append("select ");
    sql.append(session.buildSelect(User.class));
    sql.append(" where status = ? and deleted = ?");
 
    stmt = SQLUtils.prepare(conn, sql.toString(), Status.GOLD.toString(), 1);
 
    rset = stmt.executeQuery();
 
    List<User> users = new LinkedList<User>();
 
    while(rset.next()) {
        User u = new User();
        session.populateBean(rset, u);
        users.add(u);
    }
 
    System.out.println("Total de usuários carregados: " + users.size());
 
} finally {
    SQLUtils.close(rset, stmt, conn);
}

Sim, no XML ou via código através de createSQLQuery + Transformer num Repositorio específico. Na classe de negócios você diz entidade com aqueles mapeamentos por annotations? Eu particularmente não gosto, por além de amarrar outros recursos e misturar as coisas, é confuso demais de ver, gosto de olhar a entidade puramente, assim é mais fácil de entender o negócio. Mas se uma equipe decidir que vai ser mais prático assim e teve experiencia de sucesso, então que se respeite.

Uma coisa vocês tem razao, Hibernate (do Java) parou no tempo, sentou no sucesso, tá na hora de acordar e ter mapeamento programático, pois no NHibernate do .NET é tudo perfeito nesse aspecto, por isso eu gosto tanto e seria muito bom ter isso no Java também.

Por fim, seja lá qual for opção, vai poder usar SQL do jeito que quiser mesmo, e o resultado será automaticamente populado em uma lista de uma classe, ou um valor direto no caso de query scalar.
É esse “automaticamente” que as vezes assusta… Talvez essa (na minha opinião) seja a principal desvantagem do Hibernate… Querer fazer as coisas por conta, lazy loadings, transações, a própria população das entidades, etc…

Sua argumentação é válida… Nunca vi esse NHibernate pois não trabalho com .NET, mas pelo que vc disse já me parece um avanço…

Sim, esse é o grande problema. E ter que aprender HQL, JPQL, Criteria, blah quando eu já sei SQL.

Entendo, mas se você ver que a coisa sempre vai funcionar então se torna confiável, e se quiser pode tranquilamente popular a lista de objetos na mão também para esses casos de SQL, não existem leis dentro do framework. Importante é usar o que for de consenso da equipe para sucesso da vida do projeto e conforto dos seres humanos envolvidos. No seu caso é o MentaBean, que realmente admiro o mapeamento programático.

Entendo, mas se você ver que a coisa sempre vai funcionar então se torna confiável, e se quiser pode tranquilamente popular a lista de objetos na mão também para esses casos de SQL, não existem leis dentro do framework. Importante é usar o que for de consenso da equipe para sucesso da vida do projeto e conforto dos seres humanos envolvidos. No seu caso é o MentaBean, que realmente admiro o mapeamento programático.
Talvez nem seja tanto pelo “tornar-se confiável”, mas sim pela falta de controle que vc tem sobre o framework… Quem disse que deixar tudo por conta do Hibernate é algo positivo?

Pessoal,

Acho que qualquer iniciativa que venha acrescentar possibilidades a nossa área (desenvolvimento) é válida. A adoção ou não vai depender de cada um.

Acho também que nenhum framework foi criado com a finalidade de abstrair o conhecimento do desenvolvedor e sim de facilitar as coisas. Usar um framework de ORM sem ter o mínimo conhecimento de banco de dados é loucura … isso com qualquer framework, seja hibernate/jpa ou outro qualquer.

Não duvidei do suporte à diferentes dialetos, na verdade acho isso algo bem interessante. O que quis levantar foi: SOMENTE com JPA que terei suporte à outros bancos? E a resposta é: Não.

Este ganho na produtividade existe em outros frameworks também, e nem por isso precisam fazer “mágica” pra isso. O exemplo que mais posso argumentar é o caso do MentaBean… Você monta a sql como quiser e nem por isso precisa percorrer o ResultSet manualmente para formar a lista de retorno, não importa o quão complexa seja a query.

O xml não fica “preso ao fonte”. Como a configuração não é programática, a cada alteração na sua camada de negócios (inclusão, alteração ou remoção de alguma propriedade), você deve catar a respectiva configuração no xml e alterar lá também. Ou seja, vc perde uma grande vantagem: refatoração.

1. Concordo. [=
2. Sim, mas aí você perde portabilidade. Em sistemas isso pode ser vantagem, em outros desvantagem.
3. De qualquer modo você vai precisar fazer algum arquivo que relacione o nome de uma tabela a um atributo. xml, properties, anotação, runtime ou seja lá o que for.

Eu ainda não vejo no mercado um ORM que que seja bom quanto ao Hibernate a ponto de produção + portabilidade + material no mercado + profissionais no mercado.
O Spring tem suas soluções e ainda estou para estudá-las, então me desculpe se estou ofendendo algum mano spring aí. :lol: :lol: :lol: