JDBC x Hibernate (era Repositórios DDD)

6 respostas
lucasap2005

Tenho lido bastante sobre DDD e pude perceber que a maioria recomenda a implementação do Repository uitlizar Hibernate.
No meu projeto estou usando JDBC. Quais benefícios ou malefícios que vcs sabem sobre essa minha escolha?
Me aconselham a mudar? Eu realmente não posso fazer lazy loading?

6 Respostas

Alessandro_Lazarotti

Sua dúvida não é sobre DDD nem sobre repositório, é sobre tecnologia de persistência.
Abaixo uma comparação que pode lhe ajudar:

lucasap2005

Minha duvida na verdade é sobre o que eu ganharia com Hibernate.
Ao meu ver so ganharia que nao precisaria ser feito o mapeamento objeto-relacional.
Outra dúvida é que eu li em outro tópico que com JDBC eu nao poderia fazer lazy-load, e eu nao entendi porque não?
Alguem pode explicar ae?
Valeu

Emerson_Macedo

O Hibernate você ganha muitas coisas, inclusive o Lazy load que você disse. Você pode ter Lazy-load com JDBC puro, mas terá que implementar no braço.
http://www.martinfowler.com/eaaCatalog/lazyLoad.html

sergiotaborda

lucasap2005:
Tenho lido bastante sobre DDD e pude perceber que a maioria recomenda a implementação do Repository uitlizar Hibernate.
No meu projeto estou usando JDBC. Quais benefícios ou malefícios que vcs sabem sobre essa minha escolha?
Me aconselham a mudar? Eu realmente não posso fazer lazy loading?

Entenda que o Hibernate usa JDBC por baixo dos panos, logo tudo o que o hibernate faz vc pdoe fazer também. O problema é que vc estará criando algo que já existe. Se vc quer fazer isso, vá em frente, mas se vc não quer, não pode, ou não consegue fazer isso o melhor é optar pelo hibernate. Isso é o que a maioria faz.

LaztyLoading é um padrão e pode ser implementado em qualquer tecnologia. Outro nome do LazyLoading é LateBinding. A ideia é que um objeto (A) faz referencia a outro (B), mas essa referencia é nula até que o utilizador do objeto A pede o objeto B , normalmente com A.getB(). Se isso lê no banco é um detalhe.

JDBC é mais flexivel e pode ser importante se vc está trabalhando com banco legado ou sua necessidade de processamento de dados é muito grande. Por outro lado é um bom aprendizado para depois dar valor ao Hibernate e até para entender o que ele faz e quando se deve usar um ou outro.

Y

Na verdade essa é a unica razao pra existencia do hibernate e a unica que exige que ele seja usado, mesmo assim é mais do que suficiente pra explicar seu uso.

Se voce esta desenvolvendo algo procedural, que comporta perfeitamente as implementacoes diretas em JDBC, o hibernate na verdade so vai atrapalhar. Se voce esta desenvolvendo OO, pode ate tentar comecar implementando via JDBC, mas logo vai descobrir o quanto é complicado fazer o mapeamento e provavelmente vai procurar uma ferramenta que faça.

P

Outra coisa importante a ser mencionada é a questão de manutenção, alteração e coisas afins. É muito mais fácil fazer qq mudança no banco, no código utilizando o hibernate q direto no JDBC. Se vc está fazendo um código academico, que depois nao vai precisar, talvez seja mais rápido fazer no jdbc. Se ele vai crescer, é realmente aconselhavel usar o hibernate ou jpa. É o mais indicado.
Abraços!

Criado 6 de maio de 2008
Ultima resposta 11 de mai. de 2008
Respostas 6
Participantes 6