Discussion :

[Brett.Sinclair]

Bonjour,

Dans les ORM comme JPA (Hibernate, etc.), il existe 2 manières de décrire le mapping entre une classe Java et une table dans un BD. On peut exprimer la correspondance en annotant directement les champs (ou les getters), ou bien on peut décrire la correspondance dans un fichier xml à part. En l'occurrence, dans JPA, il s'appelle orm.xml.

Personnellement, je préfère centraliser les mapping dans orm.xml. Pour deux raisons, la première est que les classes métiers restent intactes, en tout cas n'ont aucune dépendance vers l'API. Cela en facilite leur écriture, leurs tests, et leur réutilisabilité. La seconde raison est, d'après ce que j'ai lu (mais je ne l'ai jamais réellement vérifié par mon expérience), est que orm.xml permet d'accéder à plus de fonctionnalités que par les annotations.

Mais voilà, l'écrasante majorité des exemples et autres tuto utilisent essentiellement les annotations. Donc, je doute… Mes raisons sont-elles bien fondées ? Y-a-t'il des avantages dans les annotations qui m'échappent ?

J'espère que parmi les lecteurs expérimentés de ce post, certains pourront m'éclairer.

Au fait, je suis enseignant... Je maitrise normalement ces technos et mais je souhaite orienter mon cours non pas vers ce qui est spécialement facile ou fun (ça je sais faire!), mais vers ce qui sera le plus utile pour les étudiants lorsqu'ils seront intégrés dans les équipes de développement pro.

Merci d'avance

[OButterlin]

On a le choix, ça va un peu dépendre du fait qu'il y a des adaptations à faire localement pour tel ou tel client ou pour telle ou telle base de données.
Là, il vaut mieux utiliser les fichiers externes, ça évite d'avoir à recompiler les classes.

[Philippe Bastiani]

Personnellement, je préfère centraliser les mapping dans orm.xml. Pour deux raisons, la première est que les classes métiers restent intactes, en tout cas n'ont aucune dépendance vers l'API. Cela en facilite leur écriture, leurs tests, et leur réutilisabilité. La seconde raison est, d'après ce que j'ai lu (mais je ne l'ai jamais réellement vérifié par mon expérience), est que orm.xml permet d'accéder à plus de fonctionnalités que par les annotations.

Le fait que les annotations soient réparties sur plusieurs classes est un faut problème quand tu identifies clairements les packages pour ton modèle BDD ! De plus ton IDE est en mesure de clairement identifier les classe annotées...
Multiplier les sources c'est multiplier le risque de bug.... IMHO, l'ajout un fichier source pour le mapping est potentiellement une source de problème supplémentaire.
Avec du mapping direct la correspondance entité <> table est, IMHO, plus lisible car directe. D'aiileurs pour les cas simples tu n'as même pas besoin d'annotation sur tes champs...
Réutilisabilité quelle réutilisabilité ? Sauf cas simple ton modèle BDD ne sera pas ton modèle business... Donc ton modèle BDD ne devrait te servir que pour la persistence !
Rajouter des annotation (quand c'est nécessaire) est-ce plus compliqué que d'écrire un mapping XML ? En quoi les annotations gènent pour les tests ?
As-tu pensé à la validation de tes entités... on le fait aussi par annotation !
Je ne vois pas d'exemple où les annotations limitent la définition d'un schéma...

De manière générale ta question rejoint la discussion XML vs annotation : Tu remarqueras que tous les APIs (JavaEE, Spring, ...) propose toutes, de version en version, de réduire au maximum la configuration XML et sa verbosité au profit des annotations !

De mon point de vue, un fichier de mapping XML ne se justifie que dans le cas d'une maintenance d'un projet dont les auteurs initiaux on fait le choix de se passer des annotations.

a+
Philippe

[Brett.Sinclair]

Merci Philippe! Je me rallie à cette opinion. D'autant que les spécifications de JPA sont clairement orientées vers l'usage des annotations. Tu as par ailleurs raison sur les tests. L'un n'empêche pas l'autre. Je suis donc convaincu sur l'approche à donner à mes cours.

A+

[OButterlin]

Et bien si vous trouvez que modifier une classe pour le cas d'une base de données spécifique n'est pas un souci, je dirais que ça vous regarde, mais en ce qui me concerne, dans le cadre d'un progiciel, le mapping externe reste et de loin la solution la plus souple.

Pour ne citer qu'un exemple d'adaptation récurrente, on prendra le cas d'un boolean. Autant le type existe sur une base MySql, autant il n'existe pas sur du DB2 ou Oracle. Pourtant, d'un point de vue de l'entity, il est préférable de le déclarer comme Boolean.
Bref, chacun sa vison

[Philippe Bastiani]

A problème récurrent solution récurente : pour le mapping de booleen, enum ou tout autre type JPA 2.1 permet d'appliquer une fonction de mapping sous forme d'annotation ! Pour JPA <2.1 les implementatione comme Hibernate ou EclipseLink fournissent le même type de solutions mais non standard !

Après biensur si on change de DB toutes les semaines il sera préférable de définir le mapping à l'extérieur de la classe

Effectivement chacun sa vision... comme je le disais plous haut on pourrais avoir la même type discussion avec le fichier de configuration de Spring par exemple !

a+
Philippe