Guerre des frameworks Java : Spring et Hibernate

Question

Mes développeurs se livrent à une guerre civile. Dans un camp, ils ont adopté Hibernate et Spring. Dans l'autre camp, ils ont dénoncé les frameworks - ils envisagent toutefois Hibernate.

La question est la suivante : existe-t-il des surprises, des faiblesses ou des écueils sur lesquels les novices de la conversion Hibernate-Spring risquent de buter ?

---

PS : Nous avons une bibliothèque DAO qui n'est pas très sophistiquée. Je doute qu'elle ait la richesse d'Hibernate, mais elle atteint une certaine maturité (c'est-à-dire qu'elle n'a pas été modifiée dans les derniers projets qu'elle a inclus).

Answer 1

Ils ont dénoncé cadres ?

C'est dingue. Si vous n'utilisez pas un cadre standard, vous créez le vôtre. C'est toujours un cadre.

Answer 2

J'ai utilisé Hibernate un certain nombre de fois dans le passé. À chaque fois, j'ai rencontré des cas limites où la détermination de la syntaxe s'est transformée en une chasse au trésor dans la documentation, sur Google et dans les anciennes versions. C'est un outil puissant mais mal documenté (aux dernières nouvelles).

Quant à Spring, presque tous les emplois pour lesquels j'ai passé un entretien ou que j'ai examinés ces dernières années impliquaient Spring, c'est vraiment devenu le standard de facto pour Java/web. Son utilisation permettra à vos développeurs d'être plus facilement commercialisables à l'avenir, et vous sera utile car vous disposerez d'un grand nombre de personnes qui comprendront votre application.

Il est tentant, éducatif et amusant d'écrire son propre cadre. Ce n'est pas si génial en termes de résultats.

Answer 3

Hibernate présente des bizarreries, c'est certain, mais c'est parce que le problème qu'il tente de résoudre est complexe. Chaque fois que quelqu'un se plaint d'Hibernate, je lui rappelle tout le code DAO ennuyeux qu'il devrait maintenir s'il ne l'utilisait pas.

Quelques conseils :

• Hibernate ne remplace pas une bonne conception de la base de données. Les schémas Hibernate sont corrects, mais vous devrez les modifier de temps à autre.
• Au final, vous allez devoir comprendre comment Hibernate charge les classes paresseusement et comment cela affecte les choses. Hibernate modifie le bytecode Java et vous devrez tôt ou tard plonger dans les profondeurs, ne serait-ce que pour expliquer pourquoi les liens entre objets sont nuls.
• Utilisez des annotations si vous le pouvez.
• Prenez le temps d'apprendre les techniques d'optimisation des performances d'Hibernate, cela vous sauvera à long terme.

Answer 4

Si vous disposez d'une base de données assez complexe, Hibernate n'est peut-être pas fait pour vous. Au travail, nous avons une base de données assez complexe avec beaucoup de données, et Hibernate ne fonctionne pas vraiment pour nous. Nous avons commencé à utiliser iBATIS à la place. Cependant, je connais beaucoup d'ateliers de développement qui utilisent Hibernate avec succès - et il fait beaucoup de travail pour vous - donc cela vaut la peine de l'envisager.

Le printemps est un bon outil si vous savez l'utiliser correctement.

Je dirais que les cadres sont définitivement une bonne chose - comme d'autres l'ont souligné, vous ne voulez pas réinventer la roue. Spring contient beaucoup de modules, ce qui signifie que vous n'aurez pas à écrire autant de code. Ne succombez pas au syndrome du "pas inventé ici" !

Answer 5

C'est une chose (dont je me souviens) dans laquelle je suis tombé quand j'étais dans mes jours d'hibernation. Lorsque vous supprimez (plusieurs) objets enfants d'une collection (dans une entité parent) et que vous ajoutez ensuite de nouvelles entités à la même collection en une seule transaction sans vidange au milieu, Hibernate effectuera l'"insertion" avant la "suppression". Si la table enfant a une contrainte unique dans l'une de ses colonnes, et que vous pensez que vous ne la violerez pas puisque vous avez déjà supprimé des données auparavant (comme moi), préparez-vous à être frustré. Le forum Hibernate le suggère :

2. C'était un défaut de conception de la DB, une nouvelle conception ;
3. flush (ou commit si vous voulez) entre les suppressions et les insertions ;

Je ne pouvais pas faire les deux, et j'ai fini par modifier le code source d'Hibernate et le recompiler. Il ne s'agissait que d'une ligne de code. Mais l'effort pour trouver cette ligne a représenté environ 27 tasses de café et 3 nuits blanches.

Il ne s'agit là que d'un exemple des problèmes et des bizarreries que vous pouvez rencontrer lorsque vous utilisez Hibernate sans véritable expert dans votre équipe (expert : personne ayant une connaissance suffisante de la philosophie et du fonctionnement interne d'Hibernate). Votre problème, votre solution, votre nombre de litres de café et de nuits blanches peuvent varier. Mais vous comprenez l'idée.