Quando usar hibernate?

Creio que a quantidade de dados persistidos não seja um fator para decidir ou não pelo Hibernate.

quel tal sempre ?

poxa… seria interessante você usar hibernate pra criar objetos com 20 propriedades e pegar 2.000.000 de registros do banco?

acho que hibernate é bom para valores não-exorbitantes, onde um selectzinho vai retornar 2 milhões de registros

e com JDBC tradicional vc listaria 2.000.000 do banco?

com um bom controle pra não dar memory leak ou paginando daria

(bom nunca fiz o teste, são suposições hehe)

Leozin:

com um bom controle pra não dar memory leak ou paginando daria
(bom nunca fiz o teste, são suposições hehe)

Memory leak e Um OutOfMemory sao duas coisas completamente diferentes.

Olá…

Quando utilizar?..eu diria que é preferível utilizá-lo sempre que for possível e necessário. O Hibernate facilita a conexão com o BD, e agiliza muito esse processo.

Até mais

Patty

Fala galera , Bom dia !

Muito bom de se discutir este asssunto.

Estou certo em afirmar que tenho uma perca de performance em consultas(SELECT) no BD ?

scottys0:

Leozin:

com um bom controle pra não dar memory leak ou paginando daria
(bom nunca fiz o teste, são suposições hehe)

Memory leak e Um OutOfMemory sao duas coisas completamente diferentes.

perdão, é out of memory que quis me referir, to com memory leak na cabeça ainda huahuahua

mas então qual seria a melhor solução pra grande volume de dados? Utilizar hibernate sem mais?

???
Ele quer saber quando é “necessário”

Quando usar hibernate?
Quando for necessário ¬¬

falou falou e não disse nada

Olá…

Existem aqui no GUJ as seguintes discussões sobre a performance do Hibernate:

:arrow: http://www.guj.com.br/posts/list/15/31323.java
:arrow: http://www.guj.com.br/posts/list/22260.java

Mas configurando o Hibernate direitinho, ele não terá problemas com consultas…

Até mais

Patty

Leozin:

???
Ele quer saber quando é “necessário”

Quando usar hibernate?
Quando for necessário ¬¬

falou falou e não disse nada

Então como eu disse…simplesmente quando for necessário…ué…tem programadores que irão preferir utilizar JDBC puro, outros optarão pelo Hibernate…alguns momentos por você não ter intimidade com o Hibernate vai preferir JDBC…não existe uma situação real em que poderíamos dizer…“olha aqui vc utiliza Hibernate,…já aqui vc utiliza JDBC”…é questão de avaliar a situação e decidir por qual dos dois optar…

Até mais

Patty

então conclui-se que a senhorita quis dizer “use quando quiser”

nefertiti , concordo com vc…!

Melhor: eu diria quando a situação (projeto) assim exigir!!!

Até mais

Patty

Hibernate é mais útil quando a aplicação baseia-se em um modelo de domínio rico.
Muitos recursos orientados a objetos são usados.
Polimorfismo, herança, associações, composições.
Se o modelo de domínio for muito simples, pode ser mais eficiente usar outra estratégia e não ORM.

adeilton:

Hibernate é mais útil quando a aplicação baseia-se em um modelo de domínio rico.
Muitos recursos orientados a objetos são usados.
Polimorfismo, herança, associações, composições.
Se o modelo de domínio for muito simples, pode ser mais eficiente usar outra estratégia e não ORM.

boa adeilton.
Eu acrescentaria ainda que, se sua base de dados possui muitas store procedures e triggers e possui um processamento baseado em procedimentos automáticos, não é muito interessante utilizar hibernate.
Mas fora isto, e considerando o que o adeilton falou, são poucas as oportunidades que eu não usaria hibernate.

Pessoal pelo que conheço diante do utilização do hibernate vejo que não é uma boa opção para todos os tipos de aplicações.

Sistemas que fazem uso extensivo de store procedures e triggers não se beneficiam.
Visto que mapear as store procedures não é tão simples e também perde-se o desempenho mapeando as funcionalidades implementadas no BD.
Outra caso de não se utilizar é por exemplo, para o BD Oracle com seus tantos recursos disponíveis, colocar uma camada de persitencia, o Hibernate, não trará vantagens, pois perde-se todas os benefícios desse poderoso BD, o Oracle.

No entanto o Hibernate é adequado para sistemas onde a maior parte da lógica de negócios fica na própria aplicação Java.

Abraços

Rafael Oliveira

rafoli:

Pessoal pelo que conheço diante do utilização do hibernate vejo que não é uma boa opção para todos os tipos de aplicações.

Correto, para todos não.

Sendo que tirando manipulações pesadas de dados este tipod e recurso não deve ser frequente numa aplicação Java EE.

rafoli:

e
Visto que mapear as store procedures não é tão simples e também perde-se o desempenho mapeando as funcionalidades implementadas no BD.

Perde-se desempenho utilizando a JVM. Perde-se desempenho utilizando um SO multitarefa. Sem números e contexto essas afiramções não dizem nada.

Independente do o-meu-sgbd-eh-melhor-que-o-seu, todos os SGBDs modernos possuem ‘beneficios’ e sao ‘poderosos’, a coisa toda é se você prefere trabalhar dentro do banco de dados ou fora. De qualquer forma os idiomas do Hibernate conseguem utilizar razoavelmente os recursos de um banco qualquer, quando é necessária uma query muitoe specífica pode-se facilmente criar uma query nativa.

Que são grande parte das aplicações que nós desenvolvedores contruímos após o fim da era cliente-servidor, certo?

pcalcado

Vou te dar um exemplo pra melhor esclarecer o que estou dizendo…

Tenho uma aplicação feita a muito tempo em delphi onde coloquei quase toda a lógica da aplicação no BD por store procedures e triggers, ou seja quase nada no Delphi de codificação…

Vejo um caso on não se faz necessário a utilização do hibernate, no caso de uma migração por exemplo de Delphi para Java…

Quanto ao BD o Oracle que citei foi um exemplo, o que disse foi que utilizando os recursos de um BD como o da aplicação citada acima perde-se em desempenho ao mapear no Hibernate, quando se tem quase todas as funcionalidades implementadas no BD.

"não é uma boa opção para todos os tipos de aplicações"
ou seja para algumas é útil e para outras não…isso vale pra todas as ferramentas, frameworks e utilitários

Rafael Oliveira

rafoli:

Tenho uma aplicação feita a muito tempo em delphi onde coloquei quase toda a lógica da aplicação no BD por store procedures e triggers, ou seja quase nada no Delphi de codificação…

Vejo um caso on não se faz necessário a utilização do hibernate, no caso de uma migração por exemplo de Delphi para Java…

Depende. Você vai migrar a aplicação sem muito esforço, do tipo pegar a linahd e código Delphi e transformar em Java ou vai migrar o apradigma? Eu não sou especialista em Delphi para saber o que dá ou não para fazer mas supondo que estas sejam as melhores técnicas na plataforma elas ainda assim não o são na plataforma Java. Em Java você deveria realmente repensar essa arquitetura, você não vai tirar muito proveito da paltaforam desta maneira (provavelmnte é melhor continuar no Delphi).

E como eu falei sem números e contexto isso não quer dizer nada.

pcaldado

então você entendeu o que eu quis dizer ao vinnymaran, para alguns casos como o do meu exemplo talvez trazer a lógica do BD pro Java não se faz necessário, por exemplo, se quiser colocar uma camada de apresentação na Web, e com isso o Hibernate não é uma boa opção…

Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO…

Hoje não coloco funcionalidades em quase sua totalidade no BD como no exemplo do Delphi…visto que a aparente melhora de desempenho pode trazer diversos malefícios em relação a continuidade do software e sua evolução…

Abraços

Rafael Oliveira

Só para lembrar , a Sun adotou a estratégia de mapeamento pós relacional - JPA como abstração default para modelos relacionais.

Logo utilizar JDBC na mão, somente em casos bem específicos.

rafoli:

pcaldado

então você entendeu o que eu quis dizer ao vinnymaran, para alguns casos como o do meu exemplo talvez trazer a lógica do BD pro Java não se faz necessário, por exemplo, se quiser colocar uma camada de apresentação na Web, e com isso o Hibernate não é uma boa opção…

Isso não faz o menor sentido. Se você pretende mudar uma aplicação de Delphi/VB/Oracle Forms/[coloque_aqui_sua_tecnologia_do_milênio_passado_favorita] para Java/.NET, não faz o menor sentido manter a arquitetura antiga na plataforma nova, ainda mais se você pretender fazer uma aplicação com múltiplas camadas de apresentação. Além do mais, apesar de ser uma prática comum, manter lógica de negócios no banco de dados na forma de stored procedures e/ou usar o banco de dados para fazer qualquer tipo de integração entre aplicações são estratégias bem pouco efetivas para se projetar um software, sob qualquer aspecto.

E migrar de plataforma tecnológica não é um projeto NOVO?

ta difícil ein…

" Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "

se antes eu disse que não compenssa pra esse exemplo visto que está a muito tempo em uso e funcionando perfeitamente, não se faz necessário mudar a lógica implementado no BD para a lógica implementada em Java

ou seja, nesse caso DEIXA QUETO, e para projetos futuros ai vem a frase "…o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "

Abraços

Rafael Oliveira

rafoli:

ta difícil ein…

" Para futuros projetos o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "

se antes eu disse que não compenssa pra esse exemplo visto que está a muito tempo em uso e funcionando perfeitamente, não se faz necessário mudar a lógica implementado no BD para a lógica implementada em Java

ou seja, nesse caso DEIXA QUETO, e para projetos futuros ai vem a frase "…o ideal é separar todas as camadas da aplicação com isso ganhar em produtividade, reusabilidade e MANUTENÇÃO… "

Abraços

Rafael Oliveira

Eu que digo que “tá difícil”. Se funciona tão perfeitamente assim, por que diabos você vai querer perder tempo migrando tudo para Java? Se você pretende montar uma outra aplicação (digamos que uma webapp) e pretende usar banco de dados como meio de integração, sinto muito, mas você está pelo menos uns 15 anos atrasado em estratégia de integração e acho que o mundo inteiro sabe que fazer integração através de banco de dados é um imenso desastre!

oxe???

onde eu disse que é vantagem ou eu to migrando alguma coisa pra Java???..vc se pedeu na discussão

o vinnymaran perguntou “Quando usar hibernate?”…

daí eu disse que POR EXEMPLO num projeto de migração onde a lógica esta no BD não é um bom caso visto que transferir a lógica pra Java e mapear o BD pro Hibernate é custoso o que a depender do caso não compensa…ou então se optar pro mapear usando o recurso sql-query do hibernate pra executar as store procedures perde-se agora em desempenho, ou seja NESSE caso não aconselho…mas cada caso é cada caso…

Para projetos futuros aconselho a ele utilizar visto que vai se beneficiar do Hibernate ganhando em produtividade, manutenção e reusabilidade…

Entendeu minha opinião? ou ainda discorda de mim?

Rafael Oliveira

Não me perdi, eu entendi muito bem seu exemplo como suposição e não como caso real, mas eu estou discutindo aqui o valor da sua suposição e, sim, ainda continuo discordando da sua suposição

BTW, você poderia citar um caso em que mapear as suas entidades para o Hibernate pode ser tão custoso assim que não valha a pena?

mosss vc ein…

lê minha última mensagem

eu disse que CUSTOSO é mudar a lógica implementada no BD pra uma implementação em JAVA…ou seja, tempo, horas de trabalho, dinheiro, etc

e em relação a MAPEAR perde-se em desempenho, visto que é mais uma camada…

e ainda digo que CADA CASO é CADA CASO…ou seja tudo isso que eu digo pra uma aplicação pode ser insignificante, em relação ao custo gerado e desempenho alterado, e com isso compense mudar a arquitetura…

Olha o trecho da minha última mensagem

Sem entrar na discussão de vcs, acabei de fazer um sistema web para emissão de relatórios dinâmicos utilizando jasperreports + spring. Como o sistema só faz montar querys de acordo com os filtros informados para depois montar a view do relatório, eu acabei montando as querys “na mão” utilizando o DBUtils da Apache. Achei que ficou bem simples, não precisei utilizar o hibernate apenas para fazer os selects.

Daniel, acho que essa aplicação possa servir de exemplo para sua pergunta.

Att,

Marcus.

marvera:

Sem entrar na discussão de vcs, acabei de fazer um sistema web para emissão de relatórios dinâmicos utilizando jasperreports + spring. Como o sistema só faz montar querys de acordo com os filtros informados para depois montar a view do relatório, eu acabei montando as querys “na mão” utilizando o DBUtils da Apache. Achei que ficou bem simples, não precisei utilizar o hibernate apenas para fazer os selects.

Daniel, acho que essa aplicação possa servir de exemplo para sua pergunta.

Att,

Marcus.

Acho q eh por ai mesmo.

Eu soh vejo utilidade no hibernate qdo vc se depara com o tar do impedance mismatch, onde seria um parto mapear suas classes para o banco de dados. Nesse caso o ganho de uma ferramenta de mapeamento compensa qqr perda q ela possa ter em porformance.

Em paradigmas procedurais, q ainda eh maioria hj em dia, nao vejo pq nao escrever as sqls na mao, ja q o modelo das classes e o do BD eh bem parecido.

Se vc tem um paradigma procedural, como você tem modelo de classes?

Se vc tem um paradigma procedural, como você tem modelo de classes?

Nao eh o fato de existirem classes q faz com q seja orientado a objeto. Todo mundo q escreveu codigo em Delphi, por exemplo, ao escrever os eventos esta na verdade escrevendo metodos em uma classe - o TForm -mesmo q o cara nao soubesse disso. Mas nao eh por isso q vamos dizer q aquilo eh orientacao a objeto.

Eu ja vi modelos de classes q eram um espelho fiel do BD - ou vice-versa - com chave estrangeira e tudo. Nesses casos q eu digo: pra que hibernate? So pra ter uma coisa a mais pra se preocupar na hora de dar manutencao?

Ou tenta - quando necessario - fazer um modelo de dominio da melhor maneira possivel, a ai o hibernate ou qqr framework de mapeamento O-R é quase q obrigatorio. Ou segue na linguagem estruturada que nao precisa de mapeamento.

Realmente, casos de migracao devem ser analisados a parte, pois existem aqueles que e mais rapido copiar a query e jogar no java do que fazer o mapeamento.

De qualquer forma, sou da mesma opiniao da menina que postou anteriormente, vai depender do conhecimento de cada um, nao adianta por tudo em hibernate porque e da moda se vc nao sabe o que esta fazendo, pois podem ocorrer problemas e voce deve estar preparado.

Apenas para reforcar, sou da opiniao que se vc nao sabe e nao tem tempo para aprender. nao use, a empresa agradece.

Ps: Tenho que configurar meu teclado :lol:

[]s

E nem o fato de não existir classe em uma linguagem a faz menos OO.

Tenho uns projetos só com consultas com SQLs com muitas linhas (mais de mil é comum), com join de dezenas de tabelas, usando vários agrupamentos, etc e tal. Só consulta desse tipo.

Basicamente não há domínio de objetos, já que as telas normalmente apenas refletem o resultado das consultas. Não preciso de lazy loading, cache, criteria API só ia complicar a minha vida, não faço CRUD, por aí vai. Nesses casos, prefiro usar JDBC normal… pra todos os outros, prefiro Hibernate.

Diante dos benefícios citados quanto ao uso do hibernate, em que situações vocês se vêem utilizando JPA ou iBATIS, ou seja, mediante decisões de projeto quando eu devo ou não utilizar estes três frameworks citados?