Persistance Java, choisir la bonne stratégie
Par Laurent simon le mercredi, 3 août 2005, 19:39 - Comprendre - Lien permanent
Une excellente présentation de Rod Johnson.sur le choix d'une stratégie de persistance relationnel/objet. Sur la base de son expérience personnelle (Spring JDBC), il passe en revue les critères de choix des outils et des stratégies de persistance en mettant l'accent sur les erreurs et les excès courants.
Une bonne entrée en matière. Je recommande cette présentation à ceux qui abordent cette problématique. Pour ceux qui maîtrisent déjà, quelques unes de ses remarques devraient leur réveiller quelques souvenirs de leur débuts.
Commentaires
Par pitié arrête ton blog : tu me donne des complexes à chaque fois que je lis une de tes note s
Si tu continue à publier il ne me restera plus qu'une solution : manger 5 heures de java par jour pour me mettre à niveau : de quoi gâcher mes vacances
Enfin un site sur lequel on trouve des critiques objectives sur java et les technos qui l'accompagne.
Peut-être pourras-tu me répondre. Je suis en train de réaliser une étude pour faire les choix techniques d'un projet. Je pense utiliser bien sur du Java et une BDOO comme DB4O qui me paraît assez bien pour nos besoins. Maintenant je me pose la question si on doit utiliser un serveur d'application avec EJB ou non ? L'application sera initialement surtout utilisée en intranet.
Je recherche donc les arguments qui me permettront de justifier l'utilisation ou la non-utilisation de ces technos qui font un peut peur à ma hiérarchie.
Sans plus de précisions sur ton projet, je ne peux pas te dire si tu as intérêt ou non à utiliser les EJB.
Les principaux intérêts de l'utilisation d'EJB pour construire les services d'une application sont (liste non exhaustive, limitée à l'essentiel):
Les EJB ont un coût non négligeable que ce soit en temps de développement ou en ressources consommées à l'exécution. C'est beaucoup moins vrai avec la version 3.0 d'EJB, mais là, la peinture est encore un peu trop fraîche.
Ce sont les points que j'évoquais précédemment qui peuvent justifier l'utilisation d'EJB. Si tu n'as pas de besoins forts sur ces points (notamment l'aspect distribué entre applications), alors tu n'as aucune raison d'utiliser les EJB. Au contraire, tu en supporterais les contraintes sans en retirer aucun bénéfice.
Si ton application est autonome, fonctionne dans son coin sur un serveur dédié et que ses services ne sont pas appelés de façon intensive par d'autres applications, alors certainement qu'elle n'a pas besoin d'EJB. Elle n'a peut être même pas besoin d'un serveur d'application J2EE full. Ce qui est le plus simple à développer et donne les meilleurs perfs (si c'est bien fait), c'est un simple moteur de servlets (TomCat par exemple) faisant vivre des objets POJO, surtout qu'avec des objets persistants sous DB4O, tu n'as même pas besoin de système de mapping.
Ma conclusion, c'est utilise EJB si tu en attends réellement quelque chose. Aujourd'hui, utiliser EJB dans le cas contraire, c'est un peut comme prendre un semi-remorque lorsqu'on à besoin que d'un scooter:
Par-contre EJB 3.0 permettra certainement dans l'avenir, une utilisation plus générique d'EJB sans se poser trop de questions mais pour l'instant c'est tout frais. Pour une première expérience, c'est donc un peu trop risqué.
Merci pour ta réponse laurent. Rien à voir - entre nous - Spirit a fait des petits ?
Fabrice, Brossard !? (pour me parler de Spirit)
Spirit a pas mal évolué par rapport à ce que tu as connu. Il a été utilisé et est encore utilisé sur pas mal de projets. Il sera peut être un jour disponible sur le web , si je trouve le temps...
Sinon, je n'ai plus tes cordonnées. Les miennes n'ont pas changé ( stratic à online point fr). Fait moi un petit mail et nous pourrons continuer cette discussion en privé.
PS: Excuse ma réponse très tardive. La semaine dernière je n'ai même pas eut le temps de consulter les commentaires de mon blog.