Discussion :

[berceker united]

Bonjour,

Je souhaiterais que des personnes puissent m'éclairer et m'aider à trouver des arguments concernant l'intérêt d'Hibernate.

J'ai intégré une équipe utilisant Sybase, Java et entre les deux Hibernate. Je suis un peu en conflit avec ce dernier. En effet, sur une application légère, Hibernate pose plus de problème qu'autre chose. C'est un petit site avec pas plus d'une dizaine de règles de gestion, pas plus de 5-8 utilisateurs connectés en même temps, moins de 10 tables SQL, BlazeDS et Java et Hibernate qui semblent mal implémentés.

De ce que j'ai vu pour l'instant, avec Hibernate on perd complètement la main sur la base de données, dans le sens où je ne peux pas optimiser les tables, placer des vues, proposer des procédures stockées où il y a une requête propre. En effet, le métier n'est pas côté base mais Java. J'ai mal à la tête lorsque je vois ce que fait faire Hibernate à la base de données concernant les requêtes SQL.
Là ou je me pose beaucoup de questions concernant les performances sur la base de données, au vu de ce que je vois passer, si jamais je fais un test de monté en charge, j'ai l'impression que les performances vont lâcher d'un coup.
Les arguments qu'on a tenté de me vendre concernant le choix d'Hibernate sont :
- Il n'y a pas besoin de créer des méthodes/fonctions dans la base de données c'est Hibernate qui gère tout, donc gain de temps et c'est lié au développement objet de l'application.
- c'est utilisé dans beaucoup d'entreprises - mmmh mouais

Jusqu'à présent l'inconvénient principal que j'ai remarqué c'est la performance et la sécurité côté base de données.

J'aimerais connaitre votre avis car je pense que ceux qui m'en parlent n'ont pas de réel d'argument convainquant, pour moi qui a mal pour notre SGBD, dont j'ai plus la main à cause d'Hibernate.
De plus, je ne voudrais pas trop critiquer Hibernate sans savoir.

Merci

[Logan Mauzaize]

L'avantage d'hibernate c'est clairement de masquer la logique relationelle aux développeurs objets et/ou d'interconnecter "facilement" des objets avec une base de données "business" existante.
La partie relationelle étant laissé aux experts en base de données (écriture des fichiers de mapping notemment).

Hibernate étant une surcouche, il y a forcément un coût en ressource. En revanche il offre une gestion (optimale ?) de cache, qui te fait gagner en performance (c'est également à prendre en compte pour les montées en charge).

Ensuite Hibernate ne te prive pas d'utiliser des vues/procédures stockées/SQL.

Quoi qu'il arrive, il faut faire un pont entre le monde relationnel de la base de données et le monde objet de Java.
La question est donc qu'est-ce qui coûte le moins en mémoire, CPU, temps de développement, robustesse du produit (les bugs ca coutent cher en argent et en image à une boîte), qualité/complexité du code, etc.

[berceker united]

L'avantage d'hibernate c'est clairement de masquer la logique relationelle aux développeurs objets et/ou d'interconnecter "facilement" des objets avec une base de données "business" existante.
La partie relationelle étant laissé aux experts en base de données (écriture des fichiers de mapping notemment).

Hibernate étant une surcouche, il y a forcément un coût en ressource. En revanche il offre une gestion (optimale ?) de cache, qui te fait gagner en performance (c'est également à prendre en compte pour les montées en charge).

Ensuite Hibernate ne te prive pas d'utiliser des vues/procédures stockées/SQL.

Quoiqu'il arrive, il faut faire un pont entre le monde relationnel de la base de données et le monde objet de Java.
La question est donc qu'est-ce qui coûte le moins en mémoire, CPU, temps de développement, robustesse du produit (les bugs ca coutent cher en argent et en image à une boîte), qualité/complexité du code, etc.

Merci pour ton intervention. En effet, je sais que lors du démarrage du serveur, il y a une monté en charge des données. Je précise bien que hibernate est mal implémenté chez nous. Lorsque je vois que le principal problème c'est hibernate, je fais le rapport coût, indisponibilité, ressource (nous allons faire venir un architecte java dont j'avais posté une annonce ici >500€/j) et la taille du site.
Tu me rassure sur le faite que je peux utiliser quand même des procédures et, je suppose, qu'hibernate, peut s'appyer dessus pour faire appelle à des données ou écrire dans la base. Je pensais qu'hibernate n'avait pas la possibilité de faire cela et donc qu'il a pas d'autre possibilité que de faire les commande select, insert, delete.

[fr1man]

Une chose importante, c'est d'activer les logs Hibernate pour voir les requêtes SQL générées et ensuite jouer avec la config, les mappings pour minimiser les requêtes.
Hibernate, s'il est bien utilisé, ne doit pas être un frein aux performances.

[Logan Mauzaize]

Si tu restes dans le monde purement objet, effectivement hibernate ne génère du SQL que pour faire des recherches et de la "synchronisation".

En revanche tu peux utiliser le HQL pour faire des requêtes relativement complexes et même mapper les résultats vers une (ou plusieurs) autre(s) entité(s).

Ensuite tu peux, comme pour le HQL, exécuter une requête SQL que tu pourras mapper vers une (ou plusieurs) entité(s).
Avec Hibernate tu as toujours accès aux objets JDBC.

Sinon je vois pas bien l'intérêt des procédures stockées si tu as implémentes toute ta logique métier dans ton code Java ?

[Rei Ichido]

Les procédures stockées sont souvent là pour des raisons de performance. Ensuite, ça veut dire que ta logique métier est éventuellement découpée (Java / BDD), et donc que tu dois avoir pour la maintenance une double compétence disponible.

[OButterlin]

De mon expérience d'Hibernate (ou autres ORM), j'ai tendance à penser qu'il est souvent mal utilisé ou trop.
Il faudrait (souvent) le restreindre au modèle métier des données, de ce point de vue, c'est un gros avantage.
Pour ce qui est des requêtes de recherche ou pour la constitution de liste de soutien, il est souvent plus performant d'utiliser une requête SQL taillée sur mesure et de créer des DTO pour l'utilisation dans l'application. On peut utiliser les indexes appropriés, utiliser les agrégats ou les fonctions SQL judicieusement etc...