Hibernate vs. iBatis ?

hibernate_logoibatisibatis_logo
Hibernate Vs. iBatis ? Lequel est le meilleur ? Lequel utiliser et quand ?
Ce sont quelques questions qui sont régulièrement posées sur les forums de discussion. Quelle est la différence entre les deux? Quels critères sont déterminants pour choisir l’un ou l’autre ? Le sujet est très intéressant, car il existe des différences majeures entre Hibernate et iBatis.

Dans le monde de la persistance en Java, il n’y a pas de solution qui soit adapté à toutes les situations. Très souvent, c’est Hibernate qui est utilisé dans les applications, mais c’est surtout parce que c’est un standard de facto.

Considérons le scénario suivant: une application exploitant Hibernate et qui fonctionne très bien ainsi. Maintenant, ajoutons des procédures stockées. Certes Hibernate propose des moyens de les appeler, il faut paramétrer un mapping, mais cela introduit plus de complexité.
Ensuite viennent les fonctionnalités de reporting, autrement dit : des requêtes qui n’ont pas de clés, des regroupements, des jointures complexes. Là encore, certes, Hibernate permet de le faire, mais la complexité augmente beaucoup. L’exercice devient nettement plus ardu, pour maintenir et faire évoluer le code, il faut faire appel à des développeurs expérimentés et il faut prendre en considération le risque d’obtenir simplement du SQL qui ne fonctionne pas.

Quel genre d’application ne fonctionne pas très bien avec un ORM ? Si l’on écarte celles reposant sur une utilisation massive de procédures stockées, les applications en questions utilisent beaucoup le SQL et notamment des requêtes avec des jointures complexes.
Autrement dit, Hibernate fonctionne très bien si le modèle de données est bien en phase avec le modèle objet, parce les ORM comme Hibernate mappent des objets sur des tables.
Supposons alors que le modèle de données n’est pas en phase avec le modèle objet. Dans ce cas, il y a beaucoup de code à ajouter et la complexité envahit votre application. On arrive au-delà du champ où l’utilisation d’un ORM est bénéfique.

Le concept ORM atteint ici ses limites. Utiliser iBatis comme une solution alternative est intéressant pour ce type de situation. En effet, iBatis mappe les result sets sur des objets, alors il n’y a pas à se soucier de la structure des tables. Cela fonctionne très bien pour les procédures stockées ou les requêtes complexes avec de nombreux regroupements et jointures tels que nécessitent les applications de reporting.

Maintenant, la question est: est-ce que cela marche bien pour des utilisations simples, type CRUD ? Bien sûr que oui! Car il suffit d’écrire du SQL. Alors pourquoi ne pas utiliser Hibernate pour ce travail?

Nous commençons à voir se profiler les critères à prendre en considération pour prendre la décision. Une question apparait: peut-on utiliser les deux ? Question intéressante, n’est-ce pas ? La réponse est: oui, bien sûr!

C’est une situation qui n’est pas si courante, pourtant nous pouvons défier les intégristes d’une solution ou d’une autre et utiliser les deux pour créer cette sorte d’hybride.
Pensez à ce type de scénario: une grosse application avec Hibernate qui fonctionne très bien. Mais il y a une fonctionnalité de reporting qui vient compliquer les choses. Ce ne sont que des requêtes, alors ce que nous pouvons faire, c’est utiliser iBatis pour gérer ces requêtes et continuer d’utiliser Hibernate pour la partie opérationnelle et les mises à jour.
Cet arrangement fonctionne bien, il ne casse pas la gestion transactionnelle et n’affecte pas les caches de premier ou second niveau. C’est une bonne solution, il n’y a pas de mauvais produits, uniquement des mauvais choix.

En conclusion

Utilisez iBatis:
– Si vous voulez créer et maintenir vos propres requêtes SQL, et ainsi garder le contrôle sur le SQL qui est exécuté.
– Si votre environnement est basé sur le modèle de donnée relationnel.
– Si vous devez travailler avec un schéma complexe pré existant

Utilisez Hibernate:
– Si votre environnement est basé sur le modèle objet et que vous voulez générer le SQL automatiquement.

Il est important de savoir qu’il existe d’autres solutions que les “traditionnels” ORM, comme le montre iBatis
Les deux solutions fonctionnent bien dans leurs domaines spécifiques. À vous de trouver l’opportunité d’utiliser les deux ensemble.

Nombre de vue : 601

COMMENTAIRES 2 commentaires

  1. hugo dit :

    Un point peut être à rajouter par contre sur le choix de l’un ou de l’autre, c’est “l’indépendance” de Hibernate vis à vis de la base utilisé.
    Je ne suis pas fan d’Hibernate à cause de la complexité qu’il induit et des problèmes de performance que l’on rencontre avec mais un point qui joue en sa faveur c’est quand même le fait qu’il puisse jouer sur toute les bases. Jouer un test sur Derby puis switcher sur Oracle c’est juste une config à changer.
    Donc j’aurais ajouté un critère : vous envisagez de supporter plusieurs bases (oui/non)

  2. Aurélien dit :

    J’ai utilisé Hibernate pour développer mon site et je ne regrette pas. Je n’ai pas tapé une seule ligne SQL dans mon code JAVA. Par contre, revers de la médaille, il faut quand même vérifier les requêtes générées (notamment les selects) quand on a pas mal de jointures. En effet, à moins d’être expert en annotations et en criteria, il arrive fréquemment que les requêtes générées ne soient pas optimisés.

AJOUTER UN COMMENTAIRE