Por que NÃO usar Hibernate + Annotation?

De uma forma concordo com você que o Hibernate é uma ferramenta muito boa, mas talvez o hibernate não satisfaça tudo o que você deseja fazer.
O hibernate é muito bom para aplicações pequenas e que não exija de consultas complexas, pois o custo computacional dele talvez peque pois se você desejar realizar algumas consultas que precise muito da máquina acho não seria a melhor opção.

Acho que para sistemas grandes e complexos acho que EJB talvez seja a melhor opção pois além de ter um suporte você irá precisar muito do servidor de aplicação. Acho que esse projeto 270 tabelas seja um projeto grande e não médio como você disse. Vale a pena analisar antes faça uma prova de conceito dos casos de usos mais complexos e veja o desempenho usando Hibernate e EJB o que for mais escalável você poderá usar.

Bem essa é apenas minha opnião não sei se é a melhor, mas deixo minha contribuição, espero que ajude em alguma coisa !

[] 's

:?:

O que vc não entendeu?
A pergunta foi exatamente essa do assunto do tópico…
Se existe algum motivo para não se usar o Hibernate, já que me foi tão indicado e comentado…

e obrigado pela opinião hebertaquino…

hebertaquino:

De uma forma concordo com você que o Hibernate é uma ferramenta muito boa, mas talvez o hibernate não satisfaça tudo o que você deseja fazer.
O hibernate é muito bom para aplicações pequenas e que não exija de consultas complexas, pois o custo computacional dele talvez peque pois se você desejar realizar algumas consultas que precise muito da máquina acho não seria a melhor opção.

Por favor defina sistemas pequenos !!! Não sei onde vc leu q hibernate é um framework pra sistemas pequenos.

Outra coisa quem disse q as consultas realizadas pelo hibernate são pesadas ??? Não conhece o LAZY e o EAGER ???

E o que teria haver o EJB com o Hibernate…vc não quis dizer JPA ???

hebertaquino:

De uma forma concordo com você que o Hibernate é uma ferramenta muito boa, mas talvez o hibernate não satisfaça tudo o que você deseja fazer.
O hibernate é muito bom para aplicações pequenas e que não exija de consultas complexas, pois o custo computacional dele talvez peque pois se você desejar realizar algumas consultas que precise muito da máquina acho não seria a melhor opção.

Acho que para sistemas grandes e complexos acho que EJB talvez seja a melhor opção pois além de ter um suporte você irá precisar muito do servidor de aplicação. Acho que esse projeto 270 tabelas seja um projeto grande e não médio como você disse. Vale a pena analisar antes faça uma prova de conceito dos casos de usos mais complexos e veja o desempenho usando Hibernate e EJB o que for mais escalável você poderá usar.

Bem essa é apenas minha opnião não sei se é a melhor, mas deixo minha contribuição, espero que ajude em alguma coisa !

[] 's

• de 270 tabelas = sistemas grandes??? Tu não viu nada ainda… e QUEM falou que hibernate é para aplicações pequenas???

poxa cara é melhor tu se explicar direito hein…

Hebert de Aquino
Sun Certificated Java Programmer
Sun Certificated Web Component Developer
Sun Certificated Business Component Developer
Sun Certificated Enterprise Architect

desse jeito vou largar mão das minhas…

Um sistema com 270 tabelas, pode ou não ser grande. Existem vários outros fatores que devem ser levados em conta para se fazer essa avaliação.

JPA (para ser mais genérico) é simplesmente um mecanismo que se desenvolveu para padronizar o tratamento que era dado a uma tarefa repetitiva (a tal da persistência). Isso é um ganho muito grande, mas naturalmente impõe algumas contrapartidas.

Cada projeto tem as suas especificidades, e a avaliação deve ser feita para cada caso. Um problema que estou enfrentando em um projeto atual é a dificuldade em se fazer e gerenciar cache de objetos quando se trabalha (por imposição das particularidades do projeto) com um mix de queries do framework e queries nativas. Mas até isso está acontecendo, em parte, por uma falha minha alguns meses atrás, quando preferi adiar essa preocupação.

Oi galera
Vou opnar um pouco, eu acho que posso ajudar
Bom eu tenho experiência no desenvolimento de sistemas e na parte de persistência de dados eu já usei procedure, hibernate e toplink , sendo assim, pude perceber que o hibernate é um excelente fremawork para persistência de dados e sua utilização não está limitada a tamanho e complexidade de sistema, é possível fazer tudo com hibernate mas é preciso conhecer o framework profundamente, o toplink também é um framework de persistência de dados, só que como o mesmo é da oracle, ele foi projetado para trabalhar com o sgbd oracle, sendo assim, algumas funcionalidades podem ser perdidas ou não funcionar corretamente caso este framework seja usado com outros banco de dados eu acho o toplink muito complexo e difícil de usar e pouco intuitivo, algumas funcionalidades do hibernate são até melhores que o toplink.
Bom, hoje em dia, eu uso o toplink no meu trabalho por imposição, mas, nos meus projetos de consultoria eu uso hibernate e anotations e nunca tive problema algum.

é isso

Oi dooda,

Essa parte não entendi direito.

Mais especificamente o ponto “MANIPULAÇÃO NA ESTRUTURA”, o que vc quer dizer com isso? Por um acaso seria incluir/excluir colunas das tabelas?

[]'s

Saindo um pouco desta questão do que é um ‘sistema grande’… o ibatis é uma alternativa interessante ao Hibernate para ser analisada, algumas provas de conceito e testes podem te indicar qual é a mlehor opção para o seu cenário…

BAHHH, pra que eu fui citar a quantidade de tabelas…
HSoiuHSoiuhSOiuhS

Concordo com diogopontual, por que citei 270 tabelas, mas defino o sistema como médio, de acordo com as funcionalidades e aplicações de uma forma geral.

Mas então, tocando barco… e o resto, como fica?

É por isso que eu gosto dos fórums…

isso fantomas…

quis dizer que, por exemplo, nosso sistema atual… gerencia toda parte de instalação, geração do BD, usuários, permissões, manutenção, atualização…

só por isso…

Outra coisa a ser analisada acho que seria o conhecimento da sua equipe num determinado framework. Se sua equipe esta no nível básico e intermediário, alguma hora vcs irão se perder e talvez o projeto não possa ter esse tempo gasto. Entao seria necessário contratar alguém que seja bom em java e JPA com Hibernate (a hora dele com certeza vai ser cara)

Por outro lado não acho legal fazer meio a meio…algumas coisas com JPA e outras com JDBC puro. Então acho q seria legal analisar isso tb.

Tamanho de projeto é algo muito pessoal, não vou questionar isso. Mas não vejo razão para não utilizar Hibernate.

Vc fala se o Hibernate implementa tudo que um DB relacional faz, certo? Não! Mas não significa que, porque não é 100%, você deva abandoná-lo. O Hibernate cobre a maioria dos casos, e pros casos extremos, o framework permite que você faça consultas SQL à mão.

Depende, a complexidade vai ser maior quanto maior é a complexidade das estruturas das tabelas. Em todo o caso, vai ser mais fácil fazer via Hibernate do que via JDBC.

Não é o foco do Hibernate a geração de relatórios (talvez Jasper Reports fosse mais apropriado). Tenho fortes convicções de que Union não é suportado pelo Hibernate (se alguém souber que é possível, me fale). Mas é como eu falei antes, para casos extremos, use o SQL puro.

Escalabilidade tem mais a ver com a estrutura dos dados no DB do que com o Hibernate. Acredito que Hibernate é mais ágil porque faz o desenvolvedor focar menos em detalhes de infraestrutura, e é fácil de manter porque há a geração de menos código.

É isso.

Entendo Giulliano…

por isso, estamos a algum tempo estudando… e testando, somos uma equipe pequena, de apenas 4 desenvolvedores, e não temos nenhum prazo a cumprir, por isso estamos apenas pesquisando e
testando arquiteturas…

e por incrivel que pareça, já aprendemos muito brincando com isso…

aquele abraço!!

Bom lá vai minha humilde opinião.

Todo projeto novo que inicio tento utilizar hibernate, os benefícios são imensos e é definitivamente a melhor solução ORM que conheço.

Quando o projeto é novo mesmo e você tem a oportunidade de gerar o banco a partir do seu domínio então, é perfeito.

Porem, vamos lá :(, quando você tem uma base legada que deve ser mantida, ou seu cliente tem um banco de dados que é criado por aquele DBA que parou a 20 anos atrás, as coisas começam a se complicar, os mapeamentos ficam difíceis e o sistema não fica muito expressivo. Ai talvez seja melhor dar uma olhada no ibatis mesmo.
Outras situações que não recomendo o hibernate: quando a lógica está no banco (em proc e coisas assim) e quando você vai trabalhar só com base OLAP. Nesses casos usa JDBC puro que vai ser melhor.

Agora a melhor coisa do hibernate, é que ele lhe permite sempre que for preciso passar por cima dele. Esta difícil fazer a consulta orientada a objeto, passe por cima de tudo e faça uma consulta nativa. Não consigo fazer aquela coisa que eu fazia com JDBC no hibernate, tem como você pegar ate o connection e ai é statement… (e assim vai, claro q não seria elegante)

Essa talvez seja a melhor característica dele, ele não é tão rígido, é bem flexível. Ajuda desde pros a pogers

Aproveitando a deixa,

eu já uso o hibernate em aplicações desktop e web, sem nenhum problema, fiz alguns testes com o JPA+toplink e também está legal.

Agora gostaria de saber, se alguém tem experiência do uso do hibernate em aplicações clusterizadas para web?

fw

pois é, realmente acredito que em últimos casos, como foi sugerido…
seja necessário fazer alguma coisa manualmente…

Agradeço todas as opiniões…

já fortificaram minha opinião de que, é necessário fazer mais testes e implementar alguns
casos específicos pra saber oq pode ser melhor…

Obrigado!!

Giulliano, o que eu quis dizer não é que hibernate seja para sistema pequeno ou não, o que é mais aconselhavél é que você em vez de hibernate utiliza entity beans, porque nem sempre a melhor opção seria o Hibernate.

Por Exemplo :
vai que você precise fazer uma consulta e nessa consulta retorne na casa de milhoes de registros você usaria Hibernate ou EntityBeans ?

Tudo bem pode ser que resolva usar LazyLoad ou Eager para resolver mas será que resolve tudo?
Talvez você acha que só hibernate resolva as coisas lembre - se que tudo começou graças ao velho JDBC.

Não quis dizer que o Hibernate faz ou deixa de fazer só quis dar minha opnião nem sempre todos tem razão de tudo, por isso que isso é grupo de discussão .

Agora faltar com respeito é outro assunto! re-pense nessa sua resposta antes de falar com os outros.

a galera eh defensora do hibernate mesmo. vai falar um pouquinho mal. :lol:

hebertaquino:

Por Exemplo :
vai que você precise fazer uma consulta e nessa consulta retorne na casa de milhoes de registros você usaria Hibernate ou EntityBeans ?

Ano = 2008
EntityBean = Hibernate (jpa)

Poise o problema eh onde eu trabalho hoje, numa instituição onde é proibido utilizar qualquer framework que não tenha suporte de IBM.
Alguns dos frameworks que não podem ser usados (Hibernate, Spring, Axis, Seam). Então dooda avalie todas as possíveis posibilidades de se tomar uma decisão nem sempre é simples.

hebertaquino:

Então dooda avalie todas as possíveis posibilidades de se tomar uma decisão nem sempre é simples.

quanto a aplicações clusterizadas tenho visto forte recomendação para uso de ejb.

hebertaquino:

Poise o problema eh onde eu trabalho hoje, numa instituição onde é proibido utilizar qualquer framework que não tenha suporte de IBM.
Alguns dos frameworks que não podem ser usados (Hibernate, Spring, Axis, Seam). Então dooda avalie todas as possíveis posibilidades de se tomar uma decisão nem sempre é simples.

JPA é uma especificação do Java, tanto faz se por traz haverá um Hibernate como provider da especificação ou outra API. Se por algum motivo bizarro vc não pode usar JPA implementado por Hibernate, utilize o próprio provider do IBM Websphere que é baseado no OpenJPA; dá na mesma que hibernate se vc usa apenas interfaces da especificação.

Eu continuo sem entender…os Entity Beans não são a mesma coisa que o Hibernate, talvez vc precise entender melhor esses conceitos. O que existe para mapear um BD hoje em dia são duas coisas JDBC e JPA. Sendo que a JPA apenas abstraiu o JDBC puro. EntityBeans no meu entender seria outra conversa.

Se vc fizer uma consulta que traz milhões de registros. Primeiro que é deselagante e desnecessário NINGUÉM é capaz de ler um milhão de registros. Mas ainda assim digamos q vc esta gerando o balanço de uma mega-empresa. Qual seria a diferença entre o Hibernate o seu EntityBeans e o JDBC ???

Não estou faltando com o respeito. Respeito muito a todos da comunidade, não interprete uma crítica como um ataque pessoal.

[]'s (sem desavenças)

No fim das contas dá no mesmo pois ambos seguem a especificação do JPA. Agora entity beans vamos frizar, são beans de entidade e desacoplados(hoje, nova especificação JSR 220), ou seja, se beneficiando do âmbito ORM, interpretados como classes de domínio de negócio.

[editei para corrigir palavras erradas]
ao abordar em uma arquitetura em um projeto grande, hibernate e JPA, podem variar de acordo com o conhecimento da equipe(preparação), disponibilidade atual do fornecedor, recursos novos, ausência de certas funcionalidades. hoje eu utilizaria o hibernate pois tenho mais experiência, controle e domínio, mas algumas facilidades com jpa, estão beneficiando o seu uso e não o desuso do hibernate.

hibernate está sendo e continuará sendo bastante utilizado, agora o que diferenciará é justamente o escopo não funcional que cada um possui como característica individual.

agora voltando ao tópico, você argumentou quanto a porque usar ou não hibernate + annotation, acho que a apresentacao do fabio é uma boa para iniciar seus questionamentos, mas falando abertamente, seria interessante um container de aplicação, ainda mais se você quer tratar recursos de escalabilidade e/ou interoperabilidade para b2b/b2c.

Existe uma boa razão para não usar o hibernate : vendor lock in. Se você está criando um ERP espera-se que vc queira ter dominio
sobre a tecnologia que usa. Caso isso não seja um problema, ignore.
Uma menos boa razão, mas também um razão é o padrão Open Session in View, que básicamente signfiica que para que o Lazy loading funcione vc tem que manter conhecimento sobre a persistencia em outras camadas. ( o correto seria open session em model )
Este padrão é um tanto ò quanto parecido com uma gambiarra e até um anti-pattern. Sem ele , o hibernate não funciona como seria esperado.

Por estas duas coisas eu não usaria o hibernate.

A opção é então criar o seu próprio mecanismo. Não me venham com a estoria de inventar a roda porque o hibernate não é perfeito. O desafio aqui é se vc tem uma equipa com capacidade para fazer esse trabalho. Se a resposta não for um sim convicto, então use o hibernate, mesmo com os seus defeitos e limitações. Inclua-o na sua arquitura e invista em aprender a usar as suas funcionalidades avançadas.

Como tudo é uma questão de escolha (trade-off).

Se o fator é desempenho, nao existe motivo pra NAO usar o hibernate.
Naquelas “consultas realmente pesadas” onde realmente fica lento usa-lo, vc pode fazer um parênteses e usar um JDBC.

Mas elas geralmente são minorias em um sistema.

sergiotaborda:

Existe uma boa razão para não usar o hibernate : vendor lock in. Se você está criando um ERP espera-se que vc queira ter dominio
sobre a tecnologia que usa. Caso isso não seja um problema, ignore.
Uma menos boa razão, mas também um razão é o padrão Open Session in View, que básicamente signfiica que para que o Lazy loading funcione vc tem que manter conhecimento sobre a persistencia em outras camadas. ( o correto seria open session em model )
Este padrão é um tanto ò quanto parecido com uma gambiarra e até um anti-pattern. Sem ele , o hibernate não funciona como seria esperado.

Por estas duas coisas eu não usaria o hibernate.

A opção é então criar o seu próprio mecanismo. Não me venham com a estoria de inventar a roda porque o hibernate não é perfeito. O desafio aqui é se vc tem uma equipa com capacidade para fazer esse trabalho. Se a resposta não for um sim convicto, então use o hibernate, mesmo com os seus defeitos e limitações. Inclua-o na sua arquitura e invista em aprender a usar as suas funcionalidades avançadas.

Como tudo é uma questão de escolha (trade-off).

Não concordo com nada que foi exposto acima…

dooda, use hibernate tranquilamente, não há nenhum motivo que justifique você não usá-lo.

sergiotaborda:

dooda:

…

…

Bom, não acho que hibernate seja o melhor para todos os momentos também (como já coloquei acima).
Mas, desculpa a ignorancia, não entendi seu contra argumento.

Só por que o pattern tem in ?View? no nome e ele termina a execução depois do view renderizado não quer dizer que sua camada de visão está tomando conhecimento da sua lógica de persistência. Pegue todos os seus componentes de visão e veja se eles tem alguma dependência com o hibernate usando esse pattern. Ainda sim, você pode usar seus relacionamentos eager (se você não gosta do pattern, mas ia ser terrível), imagine só por um momento você fazendo essa mesma coisa com JDBC, ia ser quase o mesmo que usar o hibernate eager e ainda não ia ter uma serie de outras vantagens que o hibernate lhe trás. Outra alternativa, seria ativar todos os relacionamentos antes de enviar os dados pro view (mas tb seria terrivel).

Bom volto a repetir, o legal de hibernate é você poder contorná-lo se preciso.

Acho que esse assunto não é tão simples, isso dependerá muito da sua arquitetura. Como estarão organizados suas camadas e quais framework você irá utilizar.

No caso acho que EJB poderia ser uma boa escolha principalmente se o Controle ficar no Côintainer (CMP).

O hibernate é uma execelente ferramenta eu usaria em quase todas as minhas aplicações, mas isso dependerá do domínio da aplicação e se sua equipe tem know-how para passar por alguns problemas de desenvolvimento. Se for usar o Hibernate vale a pena dá uma olhada no Spring é um excelente framework e também tem suporte a muitas coisas.

Todos os frameworks possuem vantagens e desvantagens basta saber qual dominio você irá usar e quais os problemas que você deverá saber.
Nada impede de você se dar bem usando o Hibernate.

Boa Sorte !

Acho que a thread agora tá ficando boa !

Pois não, mas a sua arquitura depende do hibernate. Ou seja, se for trocar depois a sua arquitetura não permanece imutável ( como deve). O inverso tb é verdade, se vc começa sem hibernate e depois decide adotá-lo tem que mudar a sua arquitura.
Em web é só solocar um filtro, mas em swing não. O dono do post não especificou se o sistema é web ou não… mas suponho que não é porque ele falou que é uma migração de Delphi. Logo, as ideias que estão habituados em web não se aplicam.

É tão terrivel que não é, sequer, uma opção.

Não é verdade. Usar JDBC não significa nada. O hibernate tb usa JDBC (!). O ponto é o controle. O hibernate tem um controle sobre
os dados que o JDBC puro não tem. O JDBC é como o FileInputStrem , serve para I/O. Se quer controle tem que adicionar na mão.
É muito simples criar um sistema semelhante ao hibernate. O que não é tão simples é otimizar esse sistema. Contudo não é impossivel. Quando vc tem o poder sobre o controlador vc pode criar seu proprio mecanismo. Claro, espera-se que ele faça o programador sobre com o problema do OSIV.

Mas o cara quer fazer um ERP. Um ERP não é um programa que dura 2 anos. Ele para durar muito mais tempo. O Hibernate pode ser contornado (bypassed) para queries, mas não para edições por causa dos caches. Contornar o Hibernate num estágio avançado do desenvolvimento ou até mesmo depois de implantada a primeira versão pode ser um tiro no pé se a arquitura não suportar isso. Mas se suportar, significa que o Hibernate foi isolado e não é usado directamente pelo programador. Então, nesse caso estaria criando a sua propria solução de persistencia usando o Hibernate como muleta.

Crie a sua propria solução, mesmo que por detrás dos panos use o Hibernate. quando descobrir que o Hibernate não faz o que quer vai gradualmente substituindo-o. Como falei antes: depende da eperiencia e capacidade da equipa.

Se você for tirar o hibernate da sua arquitetura você tambem vai tirar o seu Open Session On View e se você implementou direito, isso não impacta em alterações na sua camada de visão.
Se a aplicação é desktop nem precisa desse pattern (http://www.hibernate.org/43.html)

por que não é uma opção? Em alguns casos você ver que um relacionamento eager é interessante.

Digo usar JDBC no sentido de fazer querys e todas as transferencias de dados na mão, acho que você não leu a parte “e ainda não ia ter uma serie de outras vantagens que o hibernate lhe trás”. Eu sei que o hibernate usa JDBC(!). O que quiz dizer é que se você fosse fazer em JDBC puro ia ter que na sua consulta trazer todos os relacionamentos na mesma query para carregar complementamente seu “Entity” (a não ser que você implemente lazy na unha nos metodos “get” do seu entity), o que tornaria seu sistema bem mais lento.

Justamente por ser um sistema que vai ter um longo tempo de vida acho apropriado usar o Hibernate, ele vai ter muito mais problemas dando manutenção em DAOs cheios de SQL

OK

A maioria dos benchmarks divulgados na net registra a perda de performance nas consultas quando é usado algum ORM como o Hibernate. Pra mim, isso é indiscutível.
E é indiscutível também, o ganho em produtividade e agilidade no desenvolvimento de uma aplicação com ORM. Sem contar o fato de se ter um único DAO para para ser usado em todos os DBs conhecidos do mercado.

Mas acho que a questão é apurar o quanto a perda de performance prejudicará o desempenho de uma grande aplicação.

Aqui vai um sugestão:

Desenvolva com Hibernate, por exemplo.
Mantenha todo acesso (todo mesmo!) ao dados por DAOs.
Interfaces DAOs (ClienteDAO.java, por exemplo) e implementações (HibernateClienteDAOImpl.java) com o código de queries/updates para hibernate.
Se for constatado a necessidade de dar uma “turbinada” no processamento da aplicação, escreva os mesmos DAOs em JDBC (JdbcClienteDAOImpl.java).
Se precisar modificar um SQL ou outro para um determindado DB, extenda a classe (MssqlClienteDAOImpl.java extends JdbcClienteDAOImpl.java).

Precisei adotar tal prática numa aplicação com Spring. Mas não fiz na aplicação toda. Apenas no processamento crítico (cálculo de risco com estresse em milhares de cenários), que levava 15 minutos para cada carteira. Reduziu a 3 minutos.
Apenas o módulo de risco roda com JDBC, o resto contínua em Hibernate.

Você pode passar o link de algum benchmarks serio? (estou pedindo mesmo, não duvidando)

Para testar a performace do hibernate com JDBC é preciso envolver varias entidades, é claro que uma consulta direta com JDBC vai ser mais rapido que com hibernate, se envolvermos apenas uma tabela. Agora pense no seu sistema como um todo, seu cliente tem um relacionamento com Unidade de negocio, com contatos comerciais, que tem telefones de contato e assim vai (só um exemplo), seu sistema JDBC usa o metodo “carrega” do DAO, que por sua vez faz uma mega consulta que vai precisar fazer JOIN em todo seu BD e carregar um objeto parrudo. Já o hibernate faria consultas simples tranzendo apenas o necessario e fazendo JOIN somente se for preciso.

bom enfim da uma olhada http://www.hibernate.org/15.html

Se voce nao conhece , EJB3 Com Hibernate e o projeto e com prazos curto , vai no jdbc mesmo , e se prepara para fazer crud na mao hehe

boa sorte

the open source database benchmark
http://www.polepos.org

imola_retrieve_time.jpg750×500