Hibernate, iBatis, Java EE ou autre outil Java ORM
nous sommes en train de planifier une grande application d'entreprise. Nous concentrons nos efforts sur l'évaluation de l'hibernation après avoir connu les douleurs de J2EE.
il semble que la nouvelle API Java EE soit plus simple. J'ai aussi lu de bonnes choses sur L'hibernation et l'iBatis. Notre équipe a peu d'expérience avec les cadres.
il y a 5 points de comparaison principaux que j'aimerais déterminer.""
- apprendre Courbe/Facilité d'Utilisation
- productivité
- Maintenabilité / Stabilité
- Performance/Évolutivité
- facilité de dépannage
si vous deviez gérer une équipe de développeurs ~6 avec L'expérience J2EE quel outil ORM utiliseriez-vous et pourquoi?
12 réponses
laissez-moi essayer. Tout d'abord, j'en ai écrit sur ce sujet dans en utilisant un ORM ou un simple SQL? . Spécifiquement pour répondre à vos points:
courbe D'apprentissage / facilité d'utilisation
Ibatis est d'environ SQL. Si vous connaissez SQL, la courbe d'apprentissage de l'ibatis est insignifiante. Ibatis fait quelques choses sur le dessus de SQL tels que:
- group by;
- types discriminés; et
- dynamic SQL.
que vous aurez encore besoin d'apprendre, mais le plus grand obstacle est SQL.
JPA (qui comprend hibernation) d'autre part tente de se distancer de SQL et présente les choses dans un objet plutôt que d'une manière relationnelle. Comme Joel souligne cependant que abstractions sont fuit et JPA n'est pas une exception. Pour faire JPA vous aurez encore besoin de savoir sur relationnel modèles, SQL, optimisation des performances des requêtes et ainsi de suite.
alors Qu'Ibatis vous fera simplement appliquer le SQL que vous connaissez ou apprenez, JPA vous demandera de savoir autre chose: comment le configurer (soit XML, soit annotations). Par cela j'entends comprendre que les relations étrangères clés sont une relation (un-à-un, un-à-plusieurs ou plusieurs-à-plusieurs) d'une certaine sorte, la cartographie de type, etc.
si vous connaissez SQL, je dirais que la barrière à l'apprentissage du JPA est en fait plus élevé. Si vous ne le faites pas, C'est plutôt un résultat mitigé avec JPA vous permettant de reporter effectivement L'apprentissage du SQL pendant un certain temps (mais cela ne le retarde pas 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 de tout apprendre sur la configuration de JPA. Cela pourrait être un avantage, mais un développeur devra tout de même connaître les gestionnaires d'entités, la gestion des transactions, la gestion par opposition à l'absence de gestion. des objets et ainsi de suite.
il est intéressant de noter que JPA a également son propre langage d'interrogation (JPA-SQL), dont vous aurez besoin pour savoir si oui ou non vous connaissez SQL. Vous trouverez des situations où JPA-SQL ne peut tout simplement pas faire des choses que SQL peut.
productivité
c'est difficile à juger. Personnellement, je pense que je suis plus productif en ibatis, mais je suis aussi très à l'aise avec SQL. Certains diront qu'ils sont plus productif avec L'hibernation, mais cela est probablement dû,du moins en partie, à une méconnaissance de la SQL.
aussi la productivité avec JPA est trompeuse parce que vous tomberez de temps en temps sur un problème avec votre modèle de données ou des requêtes qui vous prend une demi-journée à une journée pour résoudre que vous tournez la journalisation et regarder ce que SQL votre fournisseur JPA produit et ensuite travailler sur la combinaison de paramètres et d'appels pour l'obtenir pour produire quelque chose qui est à la fois correct et performant.
vous n'avez tout simplement 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 à L'intérieur de PL/SQL Developer, SQL Server Management Studio, Navicat pour MySQL ou autre. Une fois que la requête est correcte, tout ce que vous faites est de cartographier les entrées et sorties.
J'ai aussi trouvé JPA-QL plus maladroite que pure SQL. Vous avez besoin d'outils séparés pour juste exécuter une requête JPA-QL pour voir les résultats et c'est quelque chose de plus que vous devez apprendre. En fait, j'ai trouvé cette partie de JPA plutôt maladroite et encombrante bien que certaines personnes l'adorent.
Maintenabilité / Stabilité
le danger avec Ibatis ici est la prolifération qui signifie que votre équipe de développement peut simplement continuer à ajouter des objets de valeur et des requêtes comme ils en ont besoin plutôt que de chercher à réutiliser alors que JPA a une entité par table et une fois que vous avez cette entité, c'est tout. Nommé requêtes ont tendance à aller sur cette entité afin sont difficiles à manquer. Les requêtes ad-hoc peuvent toujours être répétées mais je pense que c'est moins un problème potentiel.
qui vient au prix de la rigidité cependant. Souvent dans une application, vous aurez besoin de pièces et de morceaux de données provenant de différentes tables. Avec SQL c'est facile parce que vous pouvez écrire une seule requête (ou un petit nombre de requêtes) pour obtenir toutes ces données en un seul coup et les mettre dans un objet valeur personnalisé juste pour ce but.
avec JPA vous êtes en hausse que logique dans votre couche d'affaires. Les entités sont tout ou rien. Maintenant, ce n'est pas strictement vrai. Divers fournisseurs JPA vous permettront de charger partiellement des entités et ainsi de suite, mais même là, vous parlez des mêmes entitites discrètes. Si vous avez besoin de données à partir de 4 tables, vous avez besoin de 4 entités ou vous avez besoin de combiner les données que vous voulez dans une sorte d'objet valeur personnalisée dans la couche d'affaires ou de présentation.
une autre chose que j'aime chez ibatis c'est que tout votre SQL est externe (dans les fichiers XML). Certains citent cela comme un inconvénient, mais pas à moi. Vous pouvez alors trouver les utilisations d'une table et/ou d'une colonne relativement facile en effectuant une recherche dans vos fichiers XML. Avec SQL intégré dans le code (ou là où il n'y a pas de SQL du tout) il peut être beaucoup plus difficile à trouver. Vous pouvez également couper et coller SQL dans un outil de base de données et l'exécuter. Je ne peux pas exagérer assez combien de fois cela a été utile pour moi au fil des ans.
Performance/Évolutivité
ici, je pense que l'ibatis gagne haut la main. C'est du SQL simple 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. Maintenant, ce que JPA a pour avantage, c'est que la latence et le débit ne sont que rarement des problèmes. Les systèmes à haute performance existent cependant et auront tendance à défavoriser les solutions plus lourdes comme JPA.
de Plus, avec ibatis vous pouvez écrire une requête qui retourne exactement les données que vous voulez exactement les colonnes dont vous avez besoin. Fondamentalement, il n'y a aucun moyen que JPA puisse battre (ou même faire correspondre) que quand il retourne des entités discrètes.
facilité de dépannage
je pense que celui-ci est une victoire pour Ibatis aussi. Comme je l'ai mentionné ci-dessus, avec JPA vous passerez parfois une demi-journée à obtenir une requête ou une entité produire le SQL que vous voulez ou diagnostiquer un problème où une transaction échoue parce que le directeur d'entité a essayé de persister un non géré objet (qui pourrait faire partie d'un lot de travail où vous avez engagé beaucoup de travail de sorte qu'il pourrait être non trivial de trouver).
les deux échoueront si vous essayez d'utiliser une table ou une colonne qui n'existe pas, ce qui est bien.
autres critères
Maintenant vous n'avez pas mentionné la portabilité comme l'une de vos exigences (ce qui signifie passer entre les vendeurs de base de données). Il est intéressant de noter que JPA a ici l'avantage. Le les annotations sont moins portables que, par exemple, Hibernate XML (par exemple, les annotations standard JPA n'ont pas d'équivalent pour le type D'ID "natif" D'Hibernate), mais les deux sont plus portables que 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 base de données à partir de la configuration JPA. Avec ibatis vous aurez besoin d'un script pour chaque base de données.
La baisse de la portabilité est-ce que JPA est, à certains égards, le plus petit dénominateur commun, ce qui signifie que le comportement soutenu est en grande partie le comportement soutenu commun à un large éventail de fournisseurs de bases de données. Si vous souhaitez utiliser Oracle Analytics dans ibatis, aucun problème. En JPA? Eh bien, c'est un problème.
une règle empirique simpliste entre iBatis et Hibernate est que si vous voulez plus de vision SQL/relationnelle du monde, iBatis est mieux adapté; et pour la chaîne d'héritage plus complexe, et moins de vue directe à SQL, Hibernate. Les deux sont largement utilisés et solides bons cadres. Donc je pense que les deux fonctionneraient probablement bien. Peut-être lire un tutoriel pour les deux, voir si l'un sonne mieux que l'autre, et il suffit d'en choisir un.
des choses que vous énumérez, Je ne pense pas que la performance est très différent -- le goulot d'étranglement sera presque invariablement la base de données, pas le cadre. Pour d'autres choses, je pense que différents développeurs préféreraient l'un ou l'autre, c'est-à-dire qu'il n'y a pas de priorité communément acceptée (pour iBatis vs Hibernate).
la solution que vous utilisez dépend également de la conformité que vous choisissez (ou que vous devez avoir) avec les spécifications Java EE. JPA est "la norme" pour l'accès aux données dans les systèmes Java EE, donc si vous êtes particulier sur le respect de cela, vous devriez l'utiliser (avec quelques mises en garde).
JPA est une normalisation de mapping objet-relationnel systèmes. En tant que tel, il ne fournit pas une mise en œuvre, il définit simplement une approche normalisée. Hibernate entité gestionnaire est un cette mise en œuvre.
étant donné que JPA est une norme pour plusieurs fournisseurs et qu'elle est encore relativement nouvelle, il lui manque une fonctionnalité plus ésotérique qui est précieuse dans certains cas d'utilisation (par exemple, une API critères pour générer du SQL dynamique). Si vous allez avec JPA plan sur les situations où vous aurez besoin D'utiliser Hibernate directement, ou même JDBC directement. Pour des situations comme celle-ci, un modèle DAO générique est très utile; vous pouvez modifier celui-ci: accès aux données génériques Objets pour une utilisation dans JPA & JDBC assez facilement.
JPA a quelques restrictions difficiles (en particulier si vous êtes habitué à hiberner), et impose certaines approches sur vous qui sont difficiles pour les développeurs qui sont plus habitués à écrire JDBC droite. Si vous vous faites le champion de cette approche, assurez-vous de faire vos devoirs au sujet des avantages et des inconvénients de L'ORM par rapport à JDBC.
si vous allez avec JPA, une fois que vous avez atteint la courbe d'apprentissage, il va payer en termes de développement simple (en particulier si vous mettez en œuvre correctement le modèle DAO ci-dessus), mais aussi dans l'obtention de la mise en cache multi-niveaux des résultats de requête. S'il est fait correctement (un grand "si", je sais), je l'ai vu fournir de beaux avantages.
enfin, si vous avez un modèle de données legacy avec lequel vous avez peu de flexibilité, Hibernate (et JPA) vous donnera plus de maux de tête que peut-être la valeur. Par exemple:
- si la base de données ne avoir des clés primaires candidates (pour des implémentations efficaces de hashCode & égal) vous aurez besoin de faire une analyse préliminaire sur les colonnes qui définissent une rangée de façon unique -- peut-être simple, peut-être complexe selon la complexité de votre schéma;
- si vous n'êtes pas en mesure d'ajouter des colonnes version ou timestamp, vous perdez la capacité D'Hibernate de faire un verrouillage optimiste, et vous finissez par avoir à interroger avant la mise à jour.
(ajouté par la réponse au premier commentaire) Si vous êtes assez chanceux pour re-conception votre base de données, deux très importants considérations si vous allez être en utilisant un ORM:
- ajouter une colonne de numéro de version à toutes les tables pertinentes pour supporter le verrouillage optimiste.
- au cours de votre analyse de données, décider de la non-nullabilité " " alternate key " colonne (s) que les développeurs devraient utiliser pour
hashCode()&equals(). N'utilisez pas de colonnes PK dans ces méthode.
pour ajouter une autre option à la liste... regardez:
Ebean ORM ( http://ebean-orm.github.io ).
sa principale revendication serait un modèle de programmation plus simple et plus intuitif que JPA ou Hibernate. Plus précisément, il n'a pas de session D'hibernation ou D'EntityManager JPA, pas d'objets détachés/attachés (pas de fusion, persister, flush), le chargement paresseux ne fonctionne que.
... aka beaucoup plus simple à utiliser et comprendre.
vous pouvez également utiliser votre propre SQL avec Ebean (pour les requêtes, les mises à jour, les procédures stockées) et IMO il correspond Ibatis en facilité d'utilisation wrt en utilisant votre propre SQL.
si vous cherchez à utiliser L'ORM en Java SE, alors je vous suggère de vérifier.
- licence LGPL
- utiliser les annotations JPA pour la cartographie (@Entity, @OneToMany etc)
- API sans Session (Pas de fusion), persistent, rincer ... save() et delete() à la place)
- Partielle "de l'Objet" support
- Grande prise en charge des Requêtes (par objet graphique contexte de persistance) "1519150920 d'arrière-plan" requêtes
- bon support pour le traitement par lots
- Automatique de la Requête de paramétrage (via l'option "auto-extraction")
Santé, Rob.
nous travaillons actuellement sur un projet qui utilise à la fois Hibernate et ibatis. Pourquoi utiliser hibernate ? Il soutient notre modèle de domaine, les relations et l'héritage. Nous avons un modèle de domaine assez complexe et hiberante le supporte très bien. Pas besoin de s'inquiéter d'écrire des encarts, des mises à jour, etc. Ibatis est utilisé uniquement pour la vue. Il y a des requêtes et nous avons des objets de vue(similaires aux modèles de domaine mais pas aux modèles de domaine) qui sont mappés avec des requêtes. Ibatis renvoie les données dans la vue obejct vous voulez sans se soucier de la lecture de l'ensemble de résultats, que vous devez gérer au printemps JDBC. Pourquoi utiliser HQl ou Spring JDBC ? Le domaine est si complexe et lors du rendu de la vue , nous faisons des calculs , groupe par et des tonnes de fonctions SQL natives. nous faisons tout cela dans la requête, utiliser des requêtes dynamiques, Gérer les conditions dans ibatis et obtenir un objet léger propre. Fait beaucoup plus de sens si vous devez traverser plusieurs couches pour aller chercher des données en hibernation Donc, en fonction de votre situation , vous pouvez utiliser seulement un, deux ou peut-être aucun. Mais certainement, l'hibernation n'est pas quelque chose que vous ne pouvez pas vivre sans.
soyez conscient que l'utilisation de JPA/Hibernate (et probablement la plupart des autres solutions ORM) dans des applications multi-thread non-trivial peut rapidement devenir un véritable PITA parce que les sessions de base de données doivent être confinées à exactement un thread (Les objets de Session ne sont pas thread-safe). Ajoutez le chargement paresseux et le fait que les entités persistantes peuvent appartenir au plus à une session active...et vous êtes dedans pour un enfer d'un tour...
vous pourriez vouloir jeter un oeil à gestion de Session utiliser Hibernate dans une application* multi-threaded * Swing (ou simplement rechercher 'hibernate multi-threaded').
My rule of thumb (YMMV): si l'application ne se prête pas à une sorte de cycle de requête/réponse (comme un service Web par exemple) , vous pourriez probablement être mieux d'utiliser autre chose.
bien sûr, une autre solution serait de concevoir l'application de manière à contourner les limites du cadre mentionné. Changer la conception d'une application pour que je puisse faire fonctionner framework XYZ laisse un mauvais arrière-goût cependant.
de toute façon, juste mon 0,02 $151910920"
je pense que nous devrions prendre en considération la principale raison pour laquelle nous utilisons Java (ou OO).
le système doit être flexible et permettre des modifications constantes des spécifications (cela se produit très souvent dans la vie réelle). Sinon, on aurait dû programmer en C, parce que c'est beaucoup plus rapide.
Je pense que la meilleure pile pour les applications web serait Java EE: JPA-EJB - JSF (avec contexte de persistance prolongée conversation portée).
JSF est également plus lent que JSP/Servlet pur, mais il est plus rapide à développer.
JPA est plus difficile à apprendre, mais il est plus rapide à développer (vous savez: RAD) et les changements n'ont pas d'impact important (copier-coller sujet à des erreurs). Ajoutez une nouvelle colonne dans votre entité la plus utilisée, et vous devrez mettre à jour tous les relevés dans iBatis ...
JPA ne fonctionne pas très bien sur tous les cas, mais il couvre la plupart d'entre eux, et il vous permet également de brancher requête Native au lieu de JPQL sans changer de code. Mais si vous vous trouvez à écrire trop de requêtes natives, votre projet pourrait s'adapter à de meilleurs iBatis.
et en ce qui concerne la performance, JPA est aussi performant si vous comprenez comment les choses se traduisent en SQL, et si vous le mettez à faire ce qu'il est le mieux, si vous le mettez à faire quelque chose qui n'est pas confortable pour lui, il générera trop de requêtes. Il n'y a pas de magie ! Vous devez être conscient de la requête générée, pas espérer aveuglément que vous pouvez prendre la voie facile quand un cas compliqué pourrait apparaître.
en outre, si les développeurs ont toutes les capacités de SQL, ils vont écrire des requêtes trop complexes pour traiter la logique d'affaires, au lieu de l'avoir dans un endroit centralisé, vous aurez une certaine logique d'affaires en SQL, certains dans EJB. JPA doit être pour la persistance de votre modèle, pas pour la Logique Métier.
La requête de critères n'est pas non plus compatible avec la construction de requêtes dynamiques sûres nomatterhowcomplex.
Si vous êtes en effet un nouveau projet, vous pouvez utiliser hibernate, mais sachez que la courbe d'apprentissage est assez raide.
si vous avez une base de données existante, vous êtes beaucoup mieux avec iBatis, parce qu'après un jour vous êtes productif et après deux jours de plus vous pouvez tout savoir à ce sujet.
une chose que vous devez considérer est, que l'api de critères d'hibernation est excellente pour créer des requêtes personnalisées, qui selon votre application, peut être un bon argument pour elle.
si vous n'avez pas un bon modèle d'objet, Je ne vois pas l'intérêt d'hiberner. Vous avez certainement le "relationnel" dans ORM, puisque vous avez une base de données relationnelle, mais "l'objet" est la clé. Pas d'objets, pas de la moraine d'oak ridges. Je pense qu'un mapping 1:1 entre les objets et les tables, sans comportement d'objet plus riche, ne justifie pas ORM. Restez avec JDBC ou iBatis si c'est votre situation.
je suggère d'aller avec JPA et de dépendre (lourdement!) sur la durée/portée de votre projet, vous pouvez aussi bien regarder dans JPA2, car il fournit certaines des fonctionnalités manquantes de JPA (une API de requête très agréable par exemple).
va avec hibernation. Votre projet va certainement prendre de l'ampleur plus tard et l'investissement (sur l'apprentissage de l'hibernation) sera payant d'une façon ou d'une autre.
avez-vous essayé de répondre pourquoi même utiliser un outil ORM avant de décider lequel utiliser? Si vous avez des personnes dans votre équipe qui connaissent SQL, voir stick to JDBC.