Arquivo Discussoes de Programacao e Tecnologia 
Olá a todos.
Estou levantando opiniões e respostas para essa questão. É válido qualquer coisa que tenha relação com persistência de dados em java.
Por exemplo, você pode dizer simplesmente “prefiro Hibernate”, ou pode complementar citando padrões de projeto ou até mesmo banco de dados prediletos.
Essa pesquisa tem por fim centralizar conhecimento sobre persistência de dados para usuários que possam estar começando agora nesse assunto.
Muito obrigado a quem contribuir! o/
Depois de tantos anos nessa indústria vital… Eu posso dizer que depende.
Foi-se o tempo em que eu defenderia hibernate/JPA/ORM com unhas e dentes para todos os projetos, grandes ou pequenos. E foi-se, também, o tempo de defender o JDBC puro e roots com total veemência.
Hoje eu sigo a filosofia do quanto você vai aproveitar a ferramenta.
Se vai usar hibernate/JPA/ORM, faça-o a ponto de ter o máximo de aproveitamento de todas as suas funcionalidades. Com exceção do nativeQuery, obviamente.
Se é para usar nativeQuery, vai de jdbcTemplate (Spring). Ou vai de JDBC puro, mesmo.
Particularmente, eu tenho preferido usar jdbc puro. “Ah, mas se mudar o banco, você tá f0d1d0”. Ok, 10 anos trabalhando com desenvolvimento e quantas vezes mudou-se o banco no início/meio/fim do projeto? Ops, 0 vezes.
“Ah, mas hibernate/JPA facilitam muito a integração entre o java e o banco de dados”. Sim. Mas a complexidade em determinadas queries é tão alta que tem muita gente que não consegue usar nem hql, quem dirá jpql (até a versão 5, com a qual trabalhei, existia diferenças entre ambas) e o criteria/criteriabuilder (acho que é isso)? Nem comentarei sobre. E, então, o que resta, é o pessoal metendo nativeQuery em tudo. Aí o hibernate passa de solução para intermediário e qual o ganho nisso? Faz jdbc e faz as queries na mão.
Eu andei vendo no Stack Overflow e alguns sites gringos a defesa da utilização do DAO com JDBC, e vi outros dizendo que isso era um absurdo e que não deveria nunca mais utilizar isso. O pobre rapaz que postou perguntando o que deveria fazer estava confuso com tanta informação.
Acho que tudo depende, mas existem tendências e acredito que tem um porque de certas tecnologias estarem “na moda”.
Valeu pela opinião!
JDBC puro ou JDBC Template. JPA/Hibernate tem muito overhead, é mais pra quem não sabe SQL.
O que seria o overhead, efetivamente, @javaflex?
JDBC puro ou Template usa o modelo ORM? Ou DAO? E por que utilizar desses conceitos?
E, em tempo: O que o sr. pensa sobre o DDD? É válido nos dias de hoje e deve ser aplicado?
Obrigado pela resposta!
Na empresa passada em que eu estava, a gente utilizava o MyBatis, é um framework bem suave.
Nele a gente faz query sql (nativa) e então ele pega o resultado da consulta e seta no objeto de forma “automatica” praticamente. (Não sei se alguém conhece)
Eu particularmente prefiro a JPA (Spring ou JavaEE) por motivos de produtividade
Eu só ouvi falar dele, quando ainda era iBatis…
Alguns chamam o JDBCTemplate de “micro-ORM”, o fato é: não é um true ORM, mas facilita bastante trabalhar com dados de banco de dados relacionais em Java, de forma totalmente flexível e sem muito overhead de um ORM completo como Hibernate. Pra mim esse rótulo de ORM é irrelevante, importante é o resultado.
Adicionar custo pro resultado sem ter a real necessidade.
Não penso sobre DDD. Num passado distante até assisti uma apresentação sobre DDD, mas pelo que foi apresentado parecia trazer mais complexidade.
Excelente. Obrigado pela contribuição.
Flyway para manter o banco de dados. Muito bom!
Onde trabalho, usamos conceitos do DDD atrelado à uma arquitetura em microserviços. O problema que temos é na hora de definir as fronteiras, mas depois disso, tudo fica melhor de manter. Como o negócio é muito grande, o uso do conceito (DDD) aplicado à essa arquitetura facilitou muito na hora de resolver um problema, evoluir uma funcionalidade, subir a correção (deploy) e entender melhor o negócio.
Não tem haver com DDD, mas especificamente sobre entender e evoluir um negócio muito grande, BPM/BPMN é muito mais difundido e natural para todos os envolvidos. DDD para o google e pro cliente é o de telefone. Em outras palavras, é um assunto fora de cogitação.