Mas o framework não é uma boa opção para todos os tipos de aplicação. Sistemas que fazem uso
extensivo de stored procedures, triggers ou que implementam a maior parte da lógica da aplicação no
banco de dados, contando com um modelo de objetos “pobre” não vai se beneficiar com o uso do
Hibernate. Ele é mais indicado para sistemas que contam com um modelo rico, onde a maior parte da
lógica de negócios fica na própria aplicação Java, dependendo pouco de funções específicas do banco de
dados.
Como não sei qdo foi escrito este tutorial, gostaria de saber se o Hibernate funciona dessa maneira ainda ??
Mas qual arquitetura voce pretende adotar neste sistema? Voce vai ter DAOs para fazer select, insert, update e delete? Se sim, isto para mim, já justificaria a utilização do Hibernate.
Bom, qdo falei “Toda a regra de negócio dentro do BD” eu estava generalizando, vamos dizer mais precisamente que 70% ficará dentro do BD e o restante irei tratar dentro da aplicação. Mesmo assim vc acha que o hibernate me ajudaria bem pouco ??
Acho que a maneira mais facil de raciocinar sobre isto é pensar ao contrario: se não usar uma ferramenta de ORM (Object Relational Mapping), como pretende desenvolver o seu sistema? JDBC “na mão”? EJB?
Agora entre usar o iBatis ou Hibernate (ou JDO ou Toplink ou…) ai teria que analisar o seu projeto, a sua equipe de desenvolvimento, os sistemas 'legados", etc. Colocar os prós e contras cada uma das alteranativas e decidir qual usar neste projeto.