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

Soluções para problemas do JPA

Devemos pensar bem antes de simplesmente arrancar o JPA e colocar outro framework exibido aqui.

Não sou a favor de uma abordagem radical onde simplesmente arrancamos um framework de um projeto para colocar outro sem antes procurar alternativas. Diversas vezes podemos contar com soluções mais simples e menos impactantes.

Chave Composta

Infelizmente não existe muito que fazer nesse caso. Se possível, evite criar tabelas com chave composta quando não fizerem parte da regra de negócio. Já vi desenvolvedores criarem chave composta desnecessariamente e com isso acabaram por adicionar complexidade ao modelo do projeto.

Bancos Legados

A versão mais nova do JPA 2.1 já vem com suporte para StoredProcedure e Functions, desse modo é fácil adaptar seu projeto ao banco de dados legado. Se não for possível alterar a versão da implementação do JPA, pode ser que o JPA já não seja a melhor escolha para o seu projeto.

Você poderia buscar por soluções nativas do Hibernate, por exemplo, mas ainda assim perderá a portabilidade entre bancos e/ou implementações.

Tamanho do Artefato

Uma simples solução para o tamanho do artefato seria trocar de implementação, ao invés do Hibernate poderia ser utilizado Eclipselink, OpenJPA ou Batoo. O problema será se o projeto utilizar anotações/recursos próprias do Hibernate e não apenas do JPA, essa troca de implementação trará refatoração extra ao projeto.

Query Gerada e Query Complexa

A solução para esses dois problemas seria o recurso chamado NativeQuery. Com esse recurso você poderia ter sua consulta otimizada ou até mesmo simplificada, mas sacrificando a portabilidade entre banco de dados.

Existe a estratégica de colocar a consulta em um arquivo, algo como BUSCAR_ALUNOS_ORACLE e BUSCAR_ALUNOS_MYSQL, e em tempo de execução seria lido o arquivo correto. Com essa estratégia a portabilidade ainda seria possível e as consultas poderiam utilizar os recursos nativos do banco para otimizar as consultas. A desvantagem dessa abordagem é ter que manter a mesma consulta em todos os arquivos encontrados no projeto. No exemplo acima qualquer alteração na consulta seria refletida nos arquivos ORACLE e do MYSQL.

Se o seu projeto utiliza apenas de um fabricante de banco de dados, o recurso de NativeQuery não gerará problema algum.

A vantagem dessa abordagem híbrida (JPQL e NativeQuery no mesmo projeto) é justamente poder contar com as outras vantagens do JPA.

Lentidão e Memória Ocupada

O problema de lentidão e memória ocupada podem ser amenizados com as consultas otimizadas (NativeQuery), paginando a consulta e com transações pequenas.

Evitar utilizar EJB com PersistenceContext estendido também reduz a quantidade de memória utilizada pelo JPA.

Outro detalhe interessante é que ao realizar uma consulta para extrair dados apenas para leitura, por exemplo um relatório, não é necessário abrir uma transação. O código abaixo funcionaria sem problemas:

String query = "select uai from Student uai";
EntityManager entityManager = entityManagerFactory.createEntityManager();
TypedQuery<Student> typedQuery = entityManager.createQuery(query, Student.class);
List<Student> resultList = typedQuery.getResultList();

Note que na consulta acima não foi aberta uma transação explícita, com isso as entidades retornadas estarão como ‘detached’, ou seja, não monitoradas pelo JPA. Para o EJB bastaria marcar a transação como NOT_SUPPORTED e o Spring utilizar @Transactional(readOnly = true).

Complexidade

Eu consigo ver apenas um meio de resolver esse problema: estudo. É necessário ler livros, blogs, revistas e qualquer outra fonte de informações confiável. Quanto maior for o conhecimento em JPA menor serão as dúvidas e problemas no dia a dia.

Não sou um desenvolvedor radical que acredita que o JPA é a melhor solução para tudo, mas existem momentos que o JPA pode não ser a melhor escolha para o seu projeto.

É preciso ter bastante cuidado ao decidir realizar uma troca de framework de persistência, geralmente muitas classes são afetadas e um grande refactoring necessário. Diversos bugs poderão surgir por causa dessa troca. É necessário alinhar com a gerência sobre a necessidade dessa alteração e quais os impactos que virão com essa troca de framework, tantos os impactos negativos como os positivos.

Veremos nas próximas páginas 4 frameworks de persistências que são utilizados no mercado no lugar do JPA, mas antes veremos quais os critérios utilizados na escolha de cada framework.

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