Estou desenvolvendo um site utilizando Vraptor3, hibernate 3 e mysql, porem percebi que estou usando poucos recursos do hibernate, escolhi usa-lo mais por aprendizado e por achar que seria interessante, mas agora parei pra pensar e realmente nao sei se foi a melhor ideia, e como nao tenho conhecimento mais aprofundado sobre outras formas de se trabalhar o java com o BD queria saber a opinião de vcs sobre o q eu deveria usar, no caso estou usando o createSQLQuery do hibernate e escrevendo as querys na mão pq estou sem muito tempo para estudar o criteria e outros recursos que o hibernate oferece, nisso acredito estar perdendo performance ja que eu poderia usar outra forma de conexão ao BD ja q estou usando apenas querys nativas, com isso eu tiraria o hibernate fora e deixaria o site mais leve, acredito eu.
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.
[quote=renatomattos2912]A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo[/quote]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.
[quote=Hebert Coelho][quote=renatomattos2912]A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo[/quote]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. [/quote]
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
[quote=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[/quote]Diria que vale a pena criar a aplicação utilizando apenas anotações do JPA.
Caso sua aplicação seja toda anotada com JPA, para mudar de Batto para ElipseLink ou Hibernate, basta trocar o jar e o provider. [=
[quote=Hebert Coelho][quote=renatomattos2912]A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo[/quote]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. [/quote]
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”.
[quote=rmendes08][quote=Hebert Coelho][quote=renatomattos2912]A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo[/quote]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. [/quote]
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”.[/quote]
[quote=rmendes08][quote=Hebert Coelho][quote=renatomattos2912]A ideia é que futuramente tenha muitos acessos, vou dar uma estudada nesse batoo[/quote]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. [/quote]
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”.[/quote]Eu concordo mano! Digamos que faltou especificar o que seria muitos acessos. My bad! :oops: :oops: :oops:
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.
[quote=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/ [/quote]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! -_-’’
[quote=Hebert Coelho][quote=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/ [/quote]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! -_-’’[/quote]
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
