Pq usar Hibernate?

:arrow: maior produtividade
:arrow: melhor encapsulamento dos seus modelos
:arrow: maior abstração dos dados
:arrow: você não pensa em tabelas como SQL, você define seus modelos como classes/objetos, podendo usar encapsulamento, herança e etc.
:arrow: você não precisa encher seu código com linhas e mais linhas de INSERTs e UPDATES, já que o próprio hibernate faz isso.
:arrow: Independencia de Banco de dados, pois se você deseja trocar de banco de dados, apenas algumas linhas no arquivo de configuração está tudo OK.
:arrow: Aceitação cada vez maior no mercado, como você pode ver em fórum sobre Java e bastante matéria no theserverside.
:arrow: Talves seja um pouco mais díficil no começo pois precisa mudar um pouco a idéia, mas depois é muito bom

e por ae vai…

Hibernate pode aumentar muito a performance da tua aplicação já que tem suporte a lazy loading, eager loading, first-level caching, second level caching e batching. Essas são técnicas obrigatorias para se criar uma aplicação de boa performance.

Teu amigo não conhece o Hibernate ou como se desenvolve um sistema de boa performance.

O ganho em produtividade é grande, por não ter que escrever os DAOs, usar HQL em vez de SQL, ter 1 Data Mapper sempre a mão, trabalhar em termos de objetos e não ResultSets, bla bla bla…

Fora isso, usar um Domain Model sem uma ferramenta de ORM é chato pacas.

O legal do Hibernate é que ele faz a persistência de uma maneira totalmente transparente, ou seja, um bean do Hibernate não tem nada de especial. A mágica acontece no XML, que mapeia os campos do DB para os atributos do objeto.

Se o seu sistema é simples e de pouco acesso, vc até pode achar que o Hibernate seja um overkill, do mesmo jeito que EJB é um overkill em 90% dos casos.

Para a persistência trivial, isto é, ficar dando load, insert, update e delete dos seus objetos no banco de dados, fazer isso na unha com JDBC + SQL é muito chato, propenso a bugs e pouco produtivo. Para tal eu tenho a minha solução caseira de persistência chamada DBBean.

Cabe a vc decidir qual a complexidade do seu projeto e qual o melhor caminho a seguir.

Poderiam traduzir os termos lazy loading, eager loading, first-level caching, second level caching e batching, descrevendo o que são/para que serve/o que fazem?

Não entendi o que o Louds quis dizer.

Lazy Loading: digamos que eu queira pegar um objeto Pessoa do banco.

Pessoa p = ( Pessoa ) session.load( Pessoa.class, new Integer( 1 ) );

Só que eu não quero pegar os objetos Documento relacionados a esta pessoa por enquanto, portanto o banco só será acessado quando eu acessar estes objetos do objeto Pessoa.

Microfilo,

O Hibernate também dá maior independência entre SGDBs. Existem diversos dialetos de SQL. Um SQL para MySQL é ligeiramente diferente de um SQL para Oracle. Para você trocar de banco de dados, com JDBC é necessário alterar as consultas. Com o Hiber, basta mudar algumas linhas no arquivo de configuração.

Sim, existem outras formas de promover independência de SGDBs, mas Hibernate combina facilidade com adoção pela comunidade.

“Daniel Augusto”:

Poderiam traduzir os termos lazy loading, eager loading, first-level caching, second level caching e batching, descrevendo o que são/para que serve/o que fazem?

Não entendi o que o Louds quis dizer.

Lazy loading é quando se atraza a carga de dados do banco ate o último instante. Ex: Você tem as tabelas funcionario e cargo. Com lazy loading quando um registro de funcionario é lido, o correspondente em cargo será somente lido no último instante.

Eager loading é quando se adianta a carga de dados do banco e traz mais dados em uma única consulta. Ex: Como no exemplo, mas trazendo funcionario e cargo na mesma query.

first-level caching é um cache para a transação corrente, ele evita que você leia o mesmo registro do banco 2 vezes.

second-level caching é um cache para dados normalmente read-only ou raramente alterados, ele existe para a instancia da aplicação.

batching é mandar uma sequencia de comandos para o servidor em uma camada só, isso salva muito em termos de latência.

Hibernate eu acredito que seja overkill apenas quando cada tabela se envolve em um único use-case.