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

E o JDBC puro? Ainda vale a pena?

As vantagens do JDBC que podemos listar são:

  • Melhor Performance: Pelo fato de não termos nenhum framework entre a aplicação e o banco de dados a performance para ações com o banco é melhor
  • Controle total sobre o SQL: Não existirá um nenhum framework que alterará a consulta ou poderá gerar um SQL não performático. A consulta nativa será executada exatamente como foi escrita
  • Recursos Nativos: É possível ter acesso aos recursos nativos do banco de dados sem problemas, por exemplo: funções, stored procedures, hints, etc

Infelizmente também existem os aspectos negativos de se utilizar JDBC puro:

  • Código verboso: Ao receber o resultado de uma query temos que fazer manualmente a instanciação do objeto, e também precisamos chamar todos os métodos “set” necessários. Esse código fica ainda pior quando temos um relacionamento entre classes, one-to-many por exemplo. É muito comum termos um while dentro de outro while o que faz com que o código fique de difícil manutenção
  • Código frágil: Caso o nome de uma coluna na tabela mude é necessário refletir essa alteração em todas as consultas que utilizem essa consulta. Existem projetos que criam constantes com os nomes de cada tabela, o que facilitaria um pouco a manutenção (por exemplo: Customer.NAME_COLUMN). Imagine agora que uma coluna foi removida do banco de dados, nesse caso seria necessário alterar todas as consultas mesmo que existam constantes.
  • Portabilidade complexa: Se seu projeto for utilizado com mais de um banco de dados diferente seria necessário ter a mesma consulta escrita para quase todos os banco de dados. Caso uma consulta mude essa alteração teria que ser  refletida em todas as tabelas do banco, algo muito sujeito a erros na hora do desenvolvimento.

Eu vejo um fator que poderiam me fazer decidir por JDBC quase que imediatamente:

  • Performance: Se o seu projeto realizará milhares de transação por minuto, precisa ser escalável e com pouco consumo de memória esse é o seu cara. Note que eu disse milhares de transações. Geralmente projetos de médio/grande porte costumam ter essa necessidade. É possível também estudar uma abordagem híbrida para solucionar esse problema, um projeto com a maioria dele utilizando framework e apenas algumas partes utilizando JDBC

Gosto muito, já trabalhei e ainda trabalho com JDBC em alguns projetos. Apenas peço para que você não seja radical em achar que JDBC é a bala de prata para todos os problemas.

Caso você saiba algum outro motivo de vantagem/desvantagem não listado aqui em cima poste nos comentários que eu adiciono aqui dando crédito a você. [=

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