Laissez-moi essayer. Tout d'abord, j'ai déjà écrit sur ce sujet en Utiliser un ORM ou du SQL pur ? . Pour répondre spécifiquement à vos points :
Courbe d'apprentissage/Facilité d'utilisation
Ibatis concerne le SQL. Si vous connaissez SQL, la courbe d'apprentissage d'ibatis est triviale. Ibatis fait certaines choses au dessus de SQL comme :
- groupe par ;
- les types discriminés ; et
- SQL dynamique.
que vous devrez apprendre, mais le plus gros obstacle est SQL.
JPA (qui comprend Hibernate), quant à lui, tente de prendre ses distances par rapport à SQL et de présenter les choses sous forme d'objets plutôt que sous forme relationnelle. Comme Joel le souligne cependant, les abstractions sont peu fiables et JPA ne fait pas exception. Pour utiliser JPA, vous devrez toujours connaître les modèles relationnels, le langage SQL, l'optimisation des performances des requêtes, etc.
Alors qu'Ibatis vous demandera simplement d'appliquer le SQL que vous connaissez ou que vous êtes en train d'apprendre, JPA vous demandera de savoir autre chose : comment le configurer (soit en XML, soit en annotations). J'entends par là qu'il faut comprendre que les relations de type clé étrangère sont des relations (une à une, une à plusieurs ou plusieurs à plusieurs) d'un certain type, le mappage des types, etc.
Si vous connaissez SQL, je dirais que la barrière à l'apprentissage de JPA est en fait plus élevée. Si ce n'est pas le cas, le résultat est plus mitigé, JPA vous permettant effectivement de différer l'apprentissage de SQL pendant un certain temps (mais pas de le reporter indéfiniment).
Avec JPA, une fois que vous avez configuré vos entités et leurs relations, les autres développeurs peuvent simplement les utiliser et n'ont pas besoin d'apprendre tout ce qui concerne la configuration de JPA. Cela peut être un avantage, mais un développeur devra toujours connaître les gestionnaires d'entités, la gestion des transactions, les objets gérés et non gérés, etc.
Il convient de noter que JPA possède également son propre langage de requête (JPA-SQL), que vous devrez apprendre, que vous connaissiez ou non le langage SQL. Vous trouverez des situations où JPA-SQL ne peut tout simplement pas faire des choses que SQL peut faire.
Productivité
C'est une question difficile à juger. Personnellement, je pense que je suis plus productif avec ibatis, mais je suis aussi très à l'aise avec SQL. Certains diront qu'ils sont beaucoup plus productifs avec Hibernate, mais c'est peut-être dû, du moins en partie, à leur méconnaissance de SQL.
La productivité de JPA est également trompeuse, car vous rencontrerez parfois un problème avec votre modèle de données ou vos requêtes qui vous prendra une demi-journée, voire une journée, pour le résoudre. Vous devrez alors ouvrir un journal et observer le SQL produit par votre fournisseur JPA, puis trouver la combinaison de paramètres et d'appels qui lui permettra de produire quelque chose de correct et de performant.
Vous n'avez pas ce genre de problème avec Ibatis parce que vous avez écrit le SQL vous-même. Vous le testez en exécutant le SQL dans PL/SQL Developer, SQL Server Management Studio, Navicat for MySQL ou autre. Une fois que la requête est correcte, tout ce que vous faites est de mettre en correspondance les entrées et les sorties.
J'ai également trouvé que JPA-QL était plus maladroit que le SQL pur. Il faut des outils distincts pour exécuter une requête JPA-QL et voir les résultats, et c'est quelque chose de plus à apprendre. En fait, j'ai trouvé toute cette partie de JPA plutôt maladroite et peu maniable, même si certaines personnes l'adorent.
Maintenabilité/Stabilité
Le danger d'Ibatis est la prolifération, ce qui signifie que votre équipe de développement peut continuer à ajouter des objets de valeur et des requêtes au fur et à mesure de ses besoins plutôt que de chercher à les réutiliser, alors que JPA a une entité par table et une fois que vous avez cette entité, c'est tout. Les requêtes nommées ont tendance à aller sur cette entité et sont donc difficiles à manquer. Les requêtes ad hoc peuvent toujours être répétées mais je pense que c'est un problème potentiel moins important.
Cela se fait toutefois au prix d'une certaine rigidité. Souvent, dans une application, vous aurez besoin de morceaux de données provenant de différentes tables. Avec SQL, c'est facile, car vous pouvez écrire une seule requête (ou un petit nombre de requêtes) pour obtenir toutes ces données en une seule fois et les placer dans un objet de valeur personnalisé spécialement conçu à cet effet.
Avec JPA, vous déplacez cette logique dans votre couche métier. Les entités sont fondamentalement tout ou rien. Ce n'est pas tout à fait vrai. Divers fournisseurs JPA vous permettront de charger partiellement des entités, etc., mais même dans ce cas, il s'agit des mêmes entités distinctes. Si vous avez besoin de données provenant de quatre tables, vous avez besoin de quatre entités ou vous devez combiner les données que vous voulez dans une sorte d'objet de valeur personnalisé dans la couche métier ou de présentation.
Une autre chose que j'aime dans ibatis est que tout votre SQL est externe (dans des fichiers XML). Certains diront que c'est un inconvénient, mais pas moi. Vous pouvez alors trouver les utilisations d'une table et/ou d'une colonne relativement facilement en cherchant dans vos fichiers XML. Avec le SQL intégré dans le code (ou lorsqu'il n'y a pas de SQL du tout), il peut être beaucoup plus difficile de le trouver. Vous pouvez également copier et coller du SQL dans un outil de base de données et l'exécuter. Je ne saurais trop insister sur le nombre de fois où cela m'a été utile au fil des ans.
Performance/Scalabilité
Ici, je pense qu'ibatis l'emporte haut la main. C'est un SQL direct et peu coûteux. De par sa nature, JPA ne sera tout simplement pas en mesure de gérer le même niveau de latence ou de débit. Ce que JPA a de bien, c'est que la latence et le débit ne sont que rarement des problèmes. Il existe cependant des systèmes à haute performance qui auront tendance à défavoriser les solutions plus lourdes comme JPA.
De plus, avec ibatis, vous pouvez écrire une requête qui renvoie exactement les données que vous voulez avec les colonnes exactes dont vous avez besoin. Fondamentalement, il n'y a aucun moyen pour JPA de battre (ou même d'égaler) cela quand il s'agit de retourner des entités discrètes.
Facilité de dépannage
Je pense que celle-ci est une victoire pour Ibatis aussi. Comme je l'ai mentionné plus haut, avec JPA, vous passerez parfois une demi-journée à faire en sorte qu'une requête ou une entité produise le SQL que vous voulez ou à diagnostiquer un problème où une transaction échoue parce que le gestionnaire d'entités a essayé de persister un objet non géré (qui pourrait faire partie d'un travail par lot où vous avez engagé beaucoup de travail, donc il pourrait être non trivial à trouver).
Les deux échoueront si vous essayez d'utiliser une table ou une colonne qui n'existe pas, ce qui est une bonne chose.
Autres critères
Vous n'avez pas mentionné la portabilité comme l'une de vos exigences (c'est-à-dire le passage d'un fournisseur de base de données à un autre). Il est intéressant de noter qu'ici JPA a l'avantage. Les annotations sont moins portables que, par exemple, le XML d'Hibernate (par exemple, les annotations JPA standard n'ont pas d'équivalent pour le type d'ID "natif" d'Hibernate) mais les deux sont plus portables qu'ibatis / SQL.
J'ai également vu JPA / Hibernate utilisé comme une forme de DDL portable, ce qui signifie que vous exécutez un petit programme Java qui crée le schéma de la base de données à partir de la configuration JPA. Avec ibatis, vous aurez besoin d'un script pour chaque base de données supportée.
L'inconvénient de la portabilité est que JPA est, d'une certaine manière, le plus petit dénominateur commun, ce qui signifie que le comportement pris en charge est en grande partie le comportement commun pris en charge par un large éventail de fournisseurs de bases de données. Si vous voulez utiliser Oracle Analytics dans ibatis, pas de problème. Dans JPA ? Eh bien, c'est un problème.
