Choix de la technologie de persistance

Bonjour à tous !

Je suis en train de développer un logiciel de gestion de la relation clientèle pour une petite boite (je suis stagiaire là-bas).
En ce qui concerne ma base je n'ai pas encore de quoi réaliser un modèle conceptuel complet mais à vue de nez j'aurais une bonne quinzaine, voire vingtaine de tables.
A priori rien de très alambiqué ni compliqué, je recense déjà 5-6 tables seulement composés de deux champs (de simples catégories avec un id et un libellé) que j'aurais probablement pu regrouper en une seule table avec un champ discriminant mais passons :D
J'ai quelques "grosses" tables avec du many-to-one/one-to-many et j'en aurais probablement quelques unes avec du many-to-many.

J'ai assez peu d'expérience dans le développement de ce genre d'applications (avec base de donnée) et ma première expérience fut un échec . Je développais en Delphi à l'époque et j'ai eu une démarche similaire à celle que je pourrais avoir en utilisant JDBC (d'où ma crainte de retomber dans les mêmes problèmes => passer les trois quarts du temps à corriger du bug et changer la conception de mon code de persistence).

Depuis que je suis passé à Java je lorgne du côté d'hibernate qui m'a bien bluffé lorsque je l'ai testé (j'ai dû faire leur premier tutorial, donc pas allé bien loin) et je dois dire que j'ai été assez tenté de l'utiliser pour ce projet.
Mais j'ai peur de passer beaucoup trop de temps à comprendre son fonctionnement et à l'utiliser correctement.
A côté de ça je pourrais utiliser JDBC mais j'ai peur de faire du code un peu bordélique et assez peu flexible au niveau de l'utilisation.
Quand je compare à Hibernate où au final on ne fait que manipuler ses Java Beans sans se soucier de rien...

A côté de ça je viens de tomber sur JDO qui semble ressembler à Hibernate (en tous cas dans les grandes lignes) et je commence à m'y perdre.

L'application que je développe doit être multi-utilisateurs et respecter une architecture type client/serveur (en fait c'est simplement la BDD qui sera sur un serveur). A priori il ne devrait pas y avoir plus de 5 utilisateurs au total et encore moins d'utilisateurs simultanés.
Niveau matos serveurs ils ont juste un Xp pro avec plein de répertoires partagés, ils l'utilisent aussi comme station de travail (:aie:). C'est pas une foudre de guerre mais j'ai vu pire.

Donc j'ai pas de grosses contraintes de performances, mais j'aimerais quand même avoir une application réactive.

Quelle est, selon-vous qui êtes plus expérimenté, le meilleur choix à faire ?
Hibernate au risque d'impacter les performances et de se perdre dans son utilisation ?
JDBC et passer beaucoup de temps sur le code pour gérer la persistance ?

Je sais bien qu'il n'y a pas qu'une seule réponse comme en témoigne le débat qui a lieu sur l'utilisation des ORM (j'arrive plus à mettre la main sur le lien :oops:).

Je vous remercie d'avance pour vos conseils et vos réponses :)

Bonjour,

désolé j'ai pas pu de relire ton message 8O très cour hhhhhhhhh,

bien cocernant ta question , je trouve que que hibernate est une bonne api,

tu peux regarder sur le site de hibernat, en tu trouves des doc,


8O

Je ne connais pas JDO, donc aucun commentaire là dessus.

Si les performances ne sont pas critiques dans ton application, hibernate ne devrais pas trop impacter tes performances, tant que tu fait gaffe à bien utiliser le lazy loading (sinon tu charge toute la db en mémoire, et là ca impacte les performances).

Si ce sont des client lourds, t'aura plus facile à gérer les session hibernate qu'avec des client légér. Pour limiter les problème de concurrence, tu va devoir soit créer un table de lock ou tu met des identifiants d'objets que tu veux bloquer pour un utilisateur en edition (chiant à faire mais pas trop dur :p) ou rajouter une colonne "version" dans tes tables, et utiliser le versionning hibernate (ça permet à hibernate de se rendre compte lors du commit que quelqu'un d'autre a déjà modifié un enregistrement -> conflit -> l'autre à gagné ^^). Sinon les mapping hibernante sont relativement simple à faire, c'est juste la gestion de la session qui est parfois ennuyeuse avec le lazy loading (un fois la session fermée, on ne peux plus charger d'objet)

Merci pour vos réponses, je vais donc choisir Hibernate pour ce projet :)
De toutes façons je pense que j'étais trop curieux pour passer à côté :D

Très bien,

je t'assure que tu as fais un bon choix,

bonne continuation :ccool:

Effectivement Hibernate est le choix incontournable en tant qu'outil de mapping objet / relationnel.
Il est utilisé avec succès sur de très nombreux projets.

Attention cependant à bien comprendre ce qu'on fait avec sous peine de surprise, notamment au niveau performance.

bémol quand même sur le "incontournable", il existe d'autre outils de mapping plus performant mais moins complet, je pense par exemple à ibatis. Il me semble d'ailleurs qu'un regle assez courante est "si t'as le controle sur le modèle et que tu veux que tout marche automatiquement utilise hibernante, si tu es obligé d'interfacer une base de données existante, préfère ibatis"

je pense que hibernate est le leader des ORM, en effet j'ai des comparaisons et je trouve que c'est un bon outil, et notament dans la gestion des clés et les sessions ....

Si tu génère les classes du modèle avec Hibernate (ou n'importe quel ORM) et ton EDI , fais attention à ce qu'il te génère. Veille à ce qui est généré soit bien conforme à tes attentes.

Attention par ex aux associations bidirectionnelles qui peuvent être générées.

Je ne fais rien générer par Hibernate, à part le schéma de la base de données et je vérifie bien derrière que le schéma va bien correspondre à mon modèle. Si c'est pas le cas c'est que j'aurais fait une erreur quelque part ;)