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

sql2o

Esse framework trabalha com o SQL nativo e facilita a transformação do dado do banco de dados em objeto.

O código do projeto que veremos nessa página pode ser encontrado aqui: https://github.com/uaihebert/sql2oCrud

O sql2o trabalha com um objeto de conexão (Connection) próprio, bem fácil de criar:

SQ01

Note que deixamos como estático o que seria a fábrica dele conexões, e a cada utilização basta abrir uma nova conexão.

Para ler dados do banco de dados faríamos algo como:

SQ02

Note que temos o SQL nativo descrito, mas que esse SQL contém os parâmetros nominais. Ao invés de passar o parâmetro como ‘?1’ passaremos pelo nome ‘:id’. A vantagem de passar pelo nome é que em um a consulta com muitos parâmetros a mensagem de erro fala exatamente qual o parâmetro está faltando.

Outro detalhe é que a coluna que tem o nome diferente já é informada na hora da consulta, eliminando assim a necessidade de um Mapper/RowMapper. E por último note que informamos o tipo do retorno para não precisar instanciar o objeto manualmente.

Para atualizar, remover e inserir registros, basta fazer como abaixo:

SQ03

SQ04

SQ05

Um framework bem simples e objetivo de se trabalhar.

Sobre o sql2o é possível afirmar:

  • Fácil de buscar valores escalares: os valores retornados dos métodos tipo SUM, COUNT podem ser facilmente recuperados
  • Parâmetros nominais na query: facilita quando tempos um SQL com muitos parâmetros.
  • Existe a função de bind: bind é a função para popular os parâmetros automaticamente em uma query através de um objeto, mas infelizmente não funcionou no projeto por um erro no enum. Não pesquisei sobre o problema, mas imagino que seja algo fácil de se 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