Java Frameworks War: Spring et Hibernate

https://stackoverflow.com/questions/100243

01-07-2019
|

Question

Mes développeurs mènent une guerre civile. Dans un camp, ils ont embrassé Hibernate et Spring. Dans l’autre camp, ils ont dénoncé les frameworks - ils envisagent cependant d’Hibernate.

La question qui se pose est la suivante: existe-t-il de mauvaises surprises, des faiblesses ou des pièges sur lesquels les convertis débutants d’Hibernate-Spring risquent de tomber?

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

La solution

J'ai utilisé Hibernate à plusieurs reprises dans le passé. À chaque fois, j'ai rencontré des cas extrêmes dans lesquels la détermination de la syntaxe était dévolue à une chasse au trésor à travers la documentation, Google et les anciennes versions. C'est un outil puissant mais mal documenté (le dernier regardé).

En ce qui concerne Spring, pratiquement tous les emplois que j'ai interviewés ou consultés au cours des dernières années, y compris Spring, sont devenus le standard de facto pour Java / Web. Son utilisation aidera vos développeurs à être plus commercialisables à l'avenir, et cela vous aidera car vous aurez un grand nombre de personnes qui comprendront votre application.

Écrire votre propre cadre est tentant, éducatif et amusant. Pas si bon sur les résultats.

Autres conseils

Ils ont dénoncé les frameworks ?

C'est fou. Si vous n'utilisez pas de framework disponible dans le commerce, vous créez le vôtre. C'est toujours un cadre.

Hibernate a des bizarreries à faire, mais c’est parce que le problème qu’il essaie 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 conserver s'il ne l'utilisait pas.

Quelques conseils:

Hibernate ne remplace pas une bonne conception de base de données. Les schémas Hibernate sont acceptables, mais vous devrez les modifier de temps en temps
Vous devrez éventuellement comprendre comment les classes de charges paresseuses d’Hibernate et leur impact sur les choses. Hibernate modifie le bytecode Java et vous devrez explorer les profondeurs tôt ou tard si seulement pour expliquer pourquoi les liens d’objet sont nuls.
Utilisez des annotations si vous le pouvez.
Prenez le temps d'apprendre les techniques de réglage des performances d'Hibernate, cela vous fera économiser à long terme.

Si vous avez une base de données assez complexe, Hibernate pourrait ne pas vous convenir. 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 de nombreux magasins de développement qui utilisent Hibernate avec succès - et cela fait beaucoup de travail grognon pour vous -, cela vaut donc la peine d'être examiné.

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

Je dirais que les cadres sont définitivement une bonne chose - comme l'ont souligné d'autres personnes, 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 à l'option "Pas inventé ici". syndrome!

Le chargement paresseux est l’atout majeur des applications MVC qui utilisent Hibernate pour leur infrastructure de persistance. Vous chargez l'objet dans le contrôleur et le transmettez à la vue JSP. Certains ou tous les membres de la classe sont mandatés et tout explose parce que votre session Hibernate a été fermée à la fin du contrôle.

Vous devez lire l'article Ouvrir la session en vue pour comprendre le problème et obtenir un Solution. Si vous utilisez Spring, cet article de blog décrit le Solution printanière au problème de la session ouverte dans view.

C’est une chose (je me souviens bien) dans laquelle je suis tombé quand j’étais en période d’Hibernate. Lorsque vous supprimez (plusieurs) objets enfants d'une collection (dans une entité parente), puis ajoutez de nouvelles entités à la même collection dans une transaction sans passer au milieu, Hibernate insère "Insertion". avant "supprimer". Si la table enfant a une contrainte unique dans l'une de ses colonnes et si vous vous attendez à ne pas la violer, car vous avez déjà supprimé certaines données (comme je l'étais auparavant), préparez-vous à être frustré. Le forum Hibernate suggère:

C’était un défaut de conception de la base de données, une nouvelle conception;
vider (ou commettre si vous voulez) entre les suppressions et les insertions;

Je ne pouvais pas faire les deux, et j'ai fini par peaufiner la source d'Hibernate et la recompiler. Ce n'était qu'une ligne de code. Mais l’effort pour trouver cette ligne équivaut à environ 27 tasses de café et 3 nuits blanches.

Ce n’est là qu’un exemple des problèmes et des bizarreries que vous pourriez rencontrer lorsque vous utilisez Hibernate sans aucun véritable expert de votre équipe (expert: une personne ayant une connaissance suffisante de la philosophie et du fonctionnement interne d’Hibernate). Votre problème, votre solution, le litre de café et le nombre de nuits sans sommeil peuvent varier. Mais vous avez l’idée.

Je n'ai pas beaucoup travaillé avec Java, mais j'ai travaillé dans de grands groupes de développeurs Java. L'impression que j'ai eu était que le printemps est OK. Mais tout le monde était fâché à Hibernate. La moitié de l'équipe si on lui demande "Si tu pouvais changer une chose, que changerais-tu?" et ils disaient "se débarrasser d'Hibernate". Quand j'ai commencé à apprendre Hibernate, j'ai été incroyablement complexe, mais je n'ai pas appris suffisamment (heureusement, je suis passé) pour savoir si la complexité était justifiée ou non (peut-être était-il nécessaire de résoudre des problèmes complexes).

L’équipe s’est débarrassée de Spring au profit de Guice, mais c’était plutôt un changement politique, du moins de mon point de vue et des autres développeurs avec lesquels j’ai parlé.

J'ai toujours trouvé que Hibernate était un peu complexe et difficile à apprendre. Mais comme JPA (API Java Persistence) et EJB (Enterprise Java Beans) 3.0 existe depuis un certain temps, les choses sont beaucoup plus simples, je préfère de beaucoup annoter mes classes créer des mappages via JavaDoc ou XML. Consultez le prise en charge d'Hibernate . L'avantage supplémentaire est qu'il est possible (mais sans effort) de modifier ultérieurement le cadre de la base de données si nécessaire. J'ai utilisé OpenJPA avec d'excellents résultats.

Ces derniers temps, je me sers de plus en plus de JCR (référentiel de contenu Java). J'aime la façon dont mes modules peuvent partager un stockage de données unique et laisser la structure et les propriétés évoluer. Je trouve qu'il est beaucoup plus facile de travailler avec des nœuds et des propriétés plutôt que de mapper mes objets sur une base de données. Jackrabbit est une bonne implémentation.

Quant à Spring, il me plait par de nombreuses fonctionnalités, mais la quantité de XML nécessaire pour configurer signifie que je ne l’utiliserai jamais. J'utilise plutôt Guice et je l'adore.

Pour résumer, je montrerais à vos développeurs qui doutent que Hibernate leur facilitera la vie. Pour ce qui est du printemps, je vérifierais sérieusement si Guice est une alternative viable, puis j'essaierai de montrer comment Spring / Guice facilite et accélère le développement.

J'ai beaucoup travaillé sur le développement Spring / Hibernate. Au fil du temps, la façon dont les gens ont utilisé la combinaison a un peu changé. L’approche initiale de HibernateTemplate s’est avérée difficile à déboguer, car elle avalait et enveloppait des exceptions utiles; Parlez directement à l'API Hiberante!

Continuez à regarder le SQL généré (configurez votre journalisation de développement pour afficher SQL). Avoir une couche d'abstraction dans la base de données ne signifie pas que vous n'avez plus à penser en SQL; vous n'obtiendrez pas de bonnes performances si vous ne le faites pas.

Considérez le projet. J'ai choisi iBatis plutôt qu'Hibernate à plusieurs reprises, car nous avions des exigences de performances strictes, des schémas complexes complexes ou de bonnes bases de données capables d'écrire d'excellents codes SQL.

Quant à Hibernate: un très bon outil d’application qui traite un schéma de base de données qui change rapidement, un grand nombre de tables, effectue de nombreuses opérations CRUD simples. Les rapports contenant des requêtes complexes sont plutôt mal gérés. Mais dans ce cas, je préfère mélanger JDBC ou des requêtes natives. Donc, pour une réponse brève: je pense vraiment que le temps passé à apprendre Hibernate est un bon investissement (ils disent que cela est conforme aux normes EJB3.0 et JPA, également, mais cela n’a pas été pris en compte lorsque j’ai évalué cela personnellement. utiliser).

Pour ce qui est du printemps ... voir The Bile Blog :)

N'oubliez pas: les frameworks ne sont pas des puces d'argent , mais vous ne devez pas réinventez la roue non plus.

Je trouve qu’il est vraiment utile d’utiliser des frameworks bien connus tels que Hibernate car cela adapte votre code à un moule spécifique ou à une façon de penser. En d'autres termes, puisque vous utilisez Hibernate, vous écrivez du code d'une certaine manière, et la plupart des développeurs qui connaissent Hibernate, sinon tous, seront en mesure de suivre votre mode de pensée assez facilement.

Il y a bien sûr un inconvénient à cela. Avant de devenir un développeur Hibernate, vous allez découvrir que vous essayez d’insérer un carré dans un trou circulaire. Vous SAVEZ ce que vous voulez faire et comment vous étiez censé le faire avant qu'Hibernate ne soit entré en scène, mais trouver le moyen de le faire Hibernate risque de prendre un certain temps.

Néanmoins, pour les entreprises qui engagent fréquemment des consultants (qui ont besoin de comprendre beaucoup de code source dans un court laps de temps) ou dont les développeurs se connectent et abandonnent fréquemment, ou pour lesquels vous ne voulez tout simplement pas parier. Les principaux développeurs resteront à jamais et ne changeront jamais d’emploi. Hibernate et d’autres frameworks standard sont une très bonne idée, je pense.

/ Ace

Spring et Hibernate sont des frameworks difficiles à maîtriser. Ce n'est peut-être pas une bonne idée de les utiliser dans des projets avec des délais serrés tout en essayant de comprendre les cadres.

Le principal avantage des frameworks est d'essayer de fournir une plate-forme permettant à des codes cohérents d'être des produits. Par expérience, il serait judicieux de laisser les développeurs expérimentés avec les frameworks mettre en place les meilleures pratiques.

En fonction de la conception de votre application et / ou de votre base de données, vous devrez également éviter certaines bizarreries pour vous assurer que les infrastructures ne nuisent pas aux performances.

À mon avis, le principal avantage de Spring est qu’il encourage et permet de meilleures pratiques de développement, en particulier des couplages lâches, des tests et davantage d’interfaces. Hibernate sans printemps peut être très douloureux, mais les deux ensemble sont très utiles.

Adapter un projet existant à n’importe quel cadre sera difficile, mais le processus de refactorisation présente souvent de sérieux avantages pour la maintenabilité à long terme.

Je suis d'accord avec de nombreux articles sur celui-ci. J'ai utilisé les deux, largement, dans une variété de paramètres. Si je pouvais annuler une décision de conception, ce serait d’avoir utilisé Hibernate. Nous avons en fait budgété une sortie dans l'un de nos produits pour échanger Hibernate contre iBatis et Spring-JDBC pour une approche «best of all-world». Je peux faire en sorte qu'un nouveau développeur se familiarise plus rapidement avec Spring-JDBC, Spring-MVC, Spring-Ioc et iBat que si je venais de lui demander d'utiliser Hibernate.

Hibernate est trop compliqué pour ce développeur KISS. Et que Dieu vous aide en veille prolongée si votre administrateur de base de données voit le SQL généré par la base de données et vous renvoie avec des versions optimisées.

La réponse principale mentionne qu'Hibernate est mal documenté. Je conviens que le manuel de référence en ligne pourrait être plus complet. Cependant, un livre écrit par les auteurs d'Hibernate, " la persistance de Java avec Hibernate " est une lecture incontournable pour chaque utilisateur d’Hibernate et très complet.

@slim - Je suis à nouveau avec vous ce matin.

Cela ressemble à un cas classique de syndrome non inventé ici . S'ils ne sont pas friands de printemps, ils devraient envisager d'autres options plutôt que de lancer leur propre cadre (qu'ils reconnaissent le faire ou non). Guice est une possibilité. Aussi picocontainer. Il en existe d’autres, en fonction de vos besoins.

Spring et Hibernate facilitent définitivement la vie. Leur mise en route peut prendre un peu de temps au début, mais vous en bénéficierez certainement plus tard. Maintenant que le XML est remplacé par des annotations, vous n'avez pas besoin de taper des centaines de lignes XML.

Vous pouvez envisager de AppFuse pour réduire votre courbe d'apprentissage: générer une application, étudiez-le et adaptez-le, et c'est parti.

Les cadres ne sont pas mauvais. même le SDK Java est un framework.

Ce qu’ils combattent probablement, c’est la prolifération des cadres . Vous ne devriez pas apporter un cadre à un projet juste pour le coup, il devrait apporter une valeur cohérente dans un délai raisonnable. Chaque framework nécessite une courbe d'apprentissage, mais devrait vous récompenser par une productivité accrue et des fonctionnalités ultérieures.

Si vous rencontrez des difficultés avec un code difficile à déboguer en raison d'une utilisation incohérente de la base de données, de mécanismes de cache complexes ou d'une myriade d'autres raisons. Hibernate ajoutera une grande valeur. Hormis la courbe d'apprentissage (qui m'a pris environ un mois de travaux pratiques), il n'y avait pas de piège, à condition que vous disposiez de quelqu'un pour vous expliquer les bases.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow