Ainda nao consegui entender qual o "grande lance" do Hibernate

faeldix,

Não me interprete mau, mas você está muito equivocado!
Qualquer pessoa que não tenha o minimo de conhecimento em SQL será infeliz com o hibernate, ou seja, terá que aprender SQL e Hibernate.

Em relação a “funcionalidade”, não consigo imaginar o tipo de projeto que você tem trabalhado, mas é FATO, com hibernate você ganhará muito em produtividade, imagine só você substituindo todas suas classes DAO por uma generica ?

Fica uma dica, procura tutoriais que demonstrem bons exemplos com JDBC e o mesmo com Hibernate…

Boa sorte!

O grande lance do Hibernate não é a sintaxe utilizada para realizar as buscas em si, e sim a abstração que ele faz do mundo relacional para o mundo OO (ORM).

Hibernate cra sozinho sua tabela e suas entidades, vc nao precisa construir o banco primeiro, pra depois comecar a programar…
programa td em java e o hibernate cria as tabelas e os campos pra vc

Olá.

Não

O hibernate não é uma ferramenta para que o programador não tenha que aprender SQL. Um conceito importantíssimo que você não está considerando, provavelmente porque está somente estudando os conceitos e não aplicando-os profissionalmente é a produtividade.

É muito mais rápido e menos propenso a falhas fazer essas interações com o banco de dados usando o Hibernate que usando o JDBC puro, ao menos 80% delas, não tudo. E o legal é que a ferramenta te permite usar o SQL para atender essa porcentagem de atividades que por ele seriam mais complexas ou menos produtivas.

Abs

Quando iniciei com java também tinha a mesma visão que vc.
Depois de começar a trabalhar com projetos cada vez maior, observei que a produtividade e o tempo aumentaram significamente
utilizando Hibernate, Toplink etc…

um exemplo, com este método genérico você salva qualquer um registro em QUALQUER tabela, que esteja mapeada.

public T save(final T object) { manager.persist(object); return object; }

existe facilidade para consulta, update, delete, ou seja, (n) vantagens.

boa tarde faeldix.

jdbc é o acesso ao banco da linguagem java #FATO, mas como deve ter notado é EXTREMAMENTE “braçal” demanda muito trabalho manual, enquanto o hibernate mapeia as entidades 1 vez e sai usando

enquanto o HQL… ele existe… mas existem alternativas como hibernate criteria (procure no forum sobre, ou acesse http://docs.jboss.org/hibernate/core/3.3/reference/en/html/querycriteria.html )

existe tambem a vantagem da portabilidade, em teoria uma aplicaçao mapeada corretamente e com “DAO´s” bem pensados, funcionaria em qualquer banco, ja o jdbc… caiu a casa se mudo o banco.

concordo que nao parece logico resolver uma complexidade (o sql e o acesso a dados) adicionando outra (hibernate)

mas medindo os prols e contros, acredito que eh vantajoso o uso do hibernate.

Converter um objeto (classe java) em uma entidade(tabela) possibilitando a persistência do mesmo.

E quem disse que aprender JPA/Hibernate te dispensa de conhecer SQL ou banco de dados relacionais ?

Usar JPA/Hibernate simplesmente te dispensa de um trabalho que você tem que fazer cedo ou tarde para um sistema robusto: um framework de persistência. É impossível fazer um sistema grande sem centralizar o código de acesso ao banco de dados, e ao passo que o JPA define uma padronização, o Hibernate é uma boa opção de implementação.

Você pode até começar a implementar um sistema com JDBC puro, mas logo você vai encontrar alguns problemas:

• repetirá diversas vezes o mesmo tipo de código para CRUD;
• não delimitará o número de conexões com o banco;
• repetirá diversas consultas desnecessárias;
• duplicará vários objetos que representam a mesma entidade;
• precisará controlar transações concorrentes;

enfim, à medida que você encontra esses problemas e tenta resolvê-los por si, você vai descobrir a necessidade de implementar toda uma camada de persistência, para que essas atividades não fiquem misturadas com as regras de negócio. Sendo assim, é mais fácil utilizar uma implementação pronta do que escrever uma nova.

Na minha opinião, apesar de economizar muito trabalho braçal o Hibernate não é um framework simples de se usar. Quem for usar tem que entender os conceitos por trás da ferramenta: ORM, caching, controle de transações, join’s, etc.

faeldix:

Nao é mais facil pegar um livro de SQL e utilizar o JDBC?? (sou novato em java)

Mas sinceramente… to aqui tentando utilizar esse Hibernate… mas nao consigo encontrar uma “funcionalidade” pra ele… tudo o que eu faco com o JDBC (sem usar aquele bando de anotacoes… e sem consigurar um zilhao de XML’s tal)… eu faco com o JDBC…

Pelo o que me parece utilizam o Hibernate pq tem gente que nao sabe SQL… mas pra usar o Hibernate se usa uma linguagem interna se nao me engano o nome é HQL…
Nao é mais facil aprender SQL que é “padrao”??

Sei la… me ajudem a entender :roll:

Pessoal muito obrigado pelas respostas… alguem tem ideia de um bom material pra aprender Hibernate… sem que seja aqueles do tipo “veja e faca”. Odeio criar um objeto e nao saber o pq estou criando ele rs.

abs []'s

rs, boa, eu tb nao gosto desses tutoriais nao… nem sei oq estou fazendo…

uma otima documentacao é a do proprio hibernate

http://www.hibernate.org/docs

faeldix:

Pessoal muito obrigado pelas respostas… alguem tem ideia de um bom material pra aprender Hibernate… sem que seja aqueles do tipo “veja e faca”. Odeio criar um objeto e nao saber o pq estou criando ele rs.

abs []'s

http://docs.jboss.org/hibernate/core/3.6/reference/pt-BR/html/tutorial.html

em português.

As melhores referências são essa documentação que o pessoal postou e o livro Java Persistence com Hibernate, do próprio Gavin King, o cara que criou o Hibernate. Dá pra achar o livro por uns 100 reais na net.

Você está certo em querer estudar SQL. Afinal, querendo ou não, essa é a linguagem dos bancos de dados.

A questão do Hibernate/JPA é integrar o banco de dados à aplicação de forma transparente, com orientação à objetos e de forma mais prática. Uma das coisas chatas de usar JDBC puro é a questão dos bindings das tabelas, o excesso de queries que terá que criar para cada tabela, a possibilidade de falhas de sintaxe ou lógica de linguagem SQL também são aumentadas, mas mesmo assim, há casos que não dá para fugir do JDBC, a exemplo recursos de bulking update e batch.

Uma maneira bem certeira de você entender o porque usar o Hibernate é passar pelo probema de não usá-lo: use JDBC.

Sério. Faça um projeto razoável, que te tome uns 3 meses ou mais, só com JDBC.

No começo, você não vê muita diferença, mas depois de fazer o 10º DAO e ver que está repetindo tanto código, vai entender o valor de um DAO Generico
Depois de se ver brigando para fazer o mínimo gerenciamento de transação, vai entender o valor do gernciamento de transação do Hibernate
Depois de se ver desesperado para fazer buscas que retornam um objeto apenas e outra igual que retornam toda a árvore de objetos a partir deste e mais outra pra retornar só um outro objeto do agregado, vai entender pra que serve o Lazy Loading
Depois de repetir pela milésima vez uma consulta super simples, vai entender como bom ter métodos básicos de consulta prontos
Depois de brigar pra fazer consultas dinâmicas e ver seu código virar um horror, vai ver como é bom usar Criteria
Depois de perceber o tamanho do trambolho que fica cada método simples de CRUD, vai ver a beleza de fazer um CRUD no hibernate com um código simples, consiso e enxuto
Depois de perder muito tempo pra conseguir fazer muito pouco, vai ver como é bom ter produtividade.

Isso só de começo.

E quanto ao SQL, aprenda. Mesmo com Hibernate, SQL também é importante. E uma consulta nativa sempre salva o dia quando nada mais ajuda.

Grinvon:

Você está certo em querer estudar SQL. Afinal, querendo ou não, essa é a linguagem dos bancos de dados.

A questão do Hibernate/JPA é integrar o banco de dados à aplicação de forma transparente, com orientação à objetos e de forma mais prática. Uma das coisas chatas de usar JDBC puro é a questão dos bindings das tabelas, o excesso de queries que terá que criar para cada tabela, a possibilidade de falhas de sintaxe ou lógica de linguagem SQL também são aumentadas, mas mesmo assim, há casos que não dá para fugir do JDBC, a exemplo recursos de bulking update e batch.

Isso realmente ocorre. Por isso a necessidade de um fw como JPA/Hibernate.
vc tem algumas copções como JPQL ou Criteria. A que menos lhe causará erros é a Criteria. Mas veja esse exemplo:

CriteriaBuilder builder = entityManager.getCriteriaBuilder();
CriteriaQuery<Product> query = builder.createQuery(Product.class);
Root<Product> from = query.from(Product.class);
TypedQuery<Product> typedQuery = entityManager.createQuery(
    query.select(from )
    .where(
       builder.gt(from.get("price"), price)
    )
    .orderBy(builder.asc(from.get("name")))
);
List<Product> results = typedQuery.getResultList();

Vc ainda pode escrever “price” errado.

josenaldo:

Uma maneira bem certeira de você entender o porque usar o Hibernate é passar pelo probema de não usá-lo: use JDBC.

Sério. Faça um projeto razoável, que te tome uns 3 meses ou mais, só com JDBC.

No começo, você não vê muita diferença, mas depois de fazer o 10º DAO e ver que está repetindo tanto código, vai entender o valor de um DAO Genérico
Depois de se ver brigando para fazer o mínimo gerenciamento de transação, vai entender o valor do gernciamento de transação do Hibernate
Depois de se ver desesperado para fazer buscas que retornam um objeto apenas e outra igual que retornam toda a árvore de objetos a partir deste e mais outra pra retornar só um outro objeto do agregado, vai entender pra que serve o Lazy Loading
Depois de repetir pela milésima vez uma consulta super simples, vai entender como bom ter métodos básicos de consulta prontos
Depois de brigar pra fazer consultas dinâmicas e ver seu código virar um horror, vai ver como é bom usar Criteria
Depois de perceber o tamanho do trambolho que fica cada método simples de CRUD, vai ver a beleza de fazer um CRUD no hibernate com um código simples, consiso e enxuto
Depois de perder muito tempo pra conseguir fazer muito pouco, vai ver como é bom ter produtividade.

Isso só de começo.

E quanto ao SQL, aprenda. Mesmo com Hibernate, SQL também é importante. E uma consulta nativa sempre salva o dia quando nada mais ajuda.

A sugestão do josenaldo é muito boa.
O cara tem que começar caminhando descalço pra depois conhecer o valor do chinelo.
Acho que em programação vc não é obrigado a utilizar nenhuma ferramenta, mas é interessante pesar no que vc pode fazer com e sem ela.
O controle do FetchType é uma das coisas mais interessantes do JPA e do Hibernate.

Eu tenho trabalhado com um ORM que eu mesmo estou desenvolvendo.
Claro que ainda é bem modesto se comparado com um iBATIS, mas estou melhorando aos poucos: