Alternativas ao JPA Hibernate. O que usar quando o JPA não atende meu projeto?

Problemas do JPA e do Hibernate

Existem alguns momentos onde o JPA pode fazer mais mal do que bem. Abaixo serão detalhados os problemas e na próxima página serão detalhadas algumas soluções para esses problemas:

  • Chave Composta: Essa, segundo minha opinião, é a maior dor de cabeça para quem desenvolve com o JPA. Ao mapear uma chave composta estamos adicionando uma enorme complexidade ao na hora de persistir, consultar e até mesmo na hora de mapear o objeto. Ao utilizar chave composta diversos problemas poderão aparecer, sendo que alguns desses problemas são bugs das implementações.
  • Banco Legado: Um projeto onde toda a regra de negócio se encontra no banco de dados pode vir a ter problema com chamadas para StoredProcedures e/ou Functions.
  • Tamanho do Artefato: O tamanho do artefato aumentará consideravelmente ao utilizar o Hibernate como implementação. O Hibernate utiliza de diversas dependências que aumentarão o tamanho do jar/war/ear gerado. O tamanho do artefato pode ser um problema quando temos que realizar deploy do mesmo artefato em diversos servidores, mas com uma internet lenta (ou upload lento). Imagine um sistema onde a cada release é necessário atualizar 10 clientes em diferentes lugares do país. Problemas como demora no envio, arquivo corrompido e queda de conexão podem acontecer fazendo com que a equipe perca mais tempo.
  • Query Gerada: Uma das vantagens do JPA é justamente a portabilidade entre banco de dados, para essa portabilidade ser possível foi criada a linguagem JPQL/HQL para realizar as consultas. Essa vantagem pode ser uma desvantagem quando a Query gerada tem uma péssima performance por não utilizar índices criados na tabela para melhorar o desempenho da consulta.
  • Query Complexa: Existem programas que utilizam de diversas consultas complexas utilizando de diversos recursos do banco de dados, como: SUM, MAX, MIN, COUNT, HAVING, etc. Ao combinar diversos desses recursos a performance pode cair quando o JPA fizer a consulta e não utilizar indicies, ou até mesmo se ele não der suporte a uma função nativa do banco perfeita para a consulta.
  • Complexidade: Realizar um CRUD com JPA é bem simples, mas problemas podem aparecer ao começarem os relacionamentos entre as entidades, herança, cache, manipular o PersistenceUnit, PersistenceContext com muitas entidades, etc. Uma equipe composta apenas por desenvolvedores iniciantes perderá muito tempo com os detalhes do JPA.
  • Processamento lento e memória ocupada: Existem momentos onde o JPA pode apresentar lentidões como ao realizar um relatório, inserir diversos registros em lote ou até mesmo processamento de dados onde a transação fica aberta por muito tempo.

Ao ler os problemas citados acima você pode pensar: “em que momento o JPA é bom então?”. O JPA tem diversas vantagens que não serão detalhadas aqui para não fugir do tema do post, e é uma ferramenta que em muitos casos eu indico seu uso. Algumas das vantagens são: portabilidade entre bancos, diminuição do tempo gasto em desenvolvimento, facilidade na criação de consultas, otimização com cache, ter um forte apoio da comunidade, etc.

Na próxima página veremos algumas soluções que podemos aplicar em nosso projeto e evitar um grande refactoring para troca da parte de persistência. Veremos dicas de como corrigir os problemas citados aqui ou de como contornar.

20 thoughts on “Alternativas ao JPA Hibernate. O que usar quando o JPA não atende meu projeto?

  1. Excelente artigo, Hebert!

    Passei a usar primordialmente Spring JDBC Template depois de algumas experiências amargas com JPA. Encontrei também muitos desenvolvedores em caminhos parecidos.

    Ao mesmo tempo que o JPA diminui um pouco a quantidade de código e abstrai o SQL, o desenvolvedor sente-se mais “amarrado”. Ao voltar para o “JDBC”, vem uma sensação de liberdade que vários colegas já descreveram.

    Talvez possa usar uma analogia: o JPA é como um caminhão grande que tem uma grande carga e capacidade, e o JDBC seja como um carrinho pequeno, que é que mais ágil de manobrar, porém com menos funcionalidades.

    Abraço e sucesso!

  2. Olá Hebert, tudo bem?
    Antes de comentar preciso lhe agradecer e parabenizar pelo trabalho cuidadoso e profissional que vc dispensa nesse canal de informação muito importante para nós brasileiros. Obrigado mesmo!
    Na sua lista, se possível, acrescentaria o Apache Cayenne[1] e o
    DataNucleus-JDO[2]. Do Cayenne posso falar um pouco(o conheci ao
    estudar e trabalhar com o Apache Click[3] ou framework fantástico), ferramente esplêndida e produtiva. Já o JDO é o vovô das especificações por isso merece todo respeito.
    [1] http://cayenne.apache.org/
    [2] http://www.datanucleus.org/products/accessplatform_4_0/jdo/api.html
    [2] http://click.apache.org/ | http://click.avoka.com/click-examples/cayenne/tabbed-cayenne-form-page.htm#

    • Gilberto, boa tarde.

      Fico honrado pelas palavras de apoio, muito obrigado.

      Valeu pelas contribuições, assim que possível, vou adicioná-las ao post.

  3. Herbert
    Vi sua apresentacao no infoQ (http://www.infoq.com/br/presentations/quando-jpa-nao-atende), foi bem legal! Parabéns!
    O Hibernate já me tirou muitas noites de sono depois de ter que fazer “ALTER TABLE” na manutenção do banco. Além de ter descartado JPA em projetos com banco legado com muitas procedures, queries complexas e tabelas sem integridade referencial.
    Como mencionado pelos colegas, corri para o bom e velho “JDBCzão”.

  4. como de costume ótimo post. Hebert só uma sugestão, esse menu flutuante das redes sociais no lado direito do site atrapalha bastante a leitura, tirando isso parabéns pelo blog!!

  5. Olá amigo, parabéns pelo post.

    Sugiro que crie no final uma matriz relacionando as bibliotecas com o que foi avaliado:
    documentação, facilidade de uso inicial etc…

    Vai da uma incrementada legal a ele.

    • Onezino, boa noite.

      Primeiro, me perde a demora em responder. Estou muito pegado no trabalho, para você ter idéia, estou te respondendo dele enquanto um deploy não termina.

      Obrigado pela idéia, caso um dia eu venha a editar esse post com certeza colocarei a matriz.

      E, quando eu criar outros posts desse tipo, colocarei a matriz ao final.

      Obrigado por tudo.

  6. Ótimo review das ferramentas de integração cmo SGBD. Só fiquei meio frustrado por você não ter conseguido executar um projeto com jOOQ. Vim seco para ler este post querendo saber sua opinião sobre ele. Acho que merece um post a parte ou uma atualização aqui… =)

  7. Ótimo Post. Mas tipo, eu estou começando uma aplicação agora e irei fazer o teste da troca pois irei trabalhar com um site que será melhor tratado se não tiver os enormes processos do JPA/Hibernate. Mas estou enfrentando o cenario de Versionamento/Concorrencia dos dados utilizando o Spring JDBCTemplate. Hebert você conhece algum framework que trate isso, ou irei ter de implementar na mão? Abraços !

    • José, boa tarde.

      Honestamente o primeiro framework que veio em minha mentem foi o JPA. (:

      Eu só não entendi o que seria “enormes processos” do JPA. Eu honestamente só vi problema quando o JPA foi mau utilizado ou então quando existia milhares de requisições por segundo.

      Como você está usando o JDBCTemplate eu te aconselho a procurar por “spring jdbctemplate concurrency” no google e ver o que o pessoal fala.

      De cabeça não me lembro de nada que se “acople” ao Spring para fazer esse tratamento.

Leave a Comment