Discussion :

[olivier252]

Bonjour,

Etant un junior java, j'étudie en ce moment les règles des relations entre les entités et je ne perçois pas les enjeux applicatifs pour orienter le choix vers l'une ou l'autre (bidir ou unidir).

De même, j'ai du mal à savoir dans quel sens il faut saisir la logique pour exprimer les relations 1:n et n:1, exemple :
- 1 société emploie n individus : d'emblée on peut dire que on est dans un cas de @OneToMany avec un champ collection<individu> dans la classe Société

Mais qu'est ce qui empêche de raisonner à l'inverse en disant que n individus sont employés par 1 société, ce qui du coup créé une annotation @ManyToOne au niveau du champ de retour "société" dans la classe Individu ?

Merci à vous

[OButterlin]

Alors, de mon point de vue, la grande majorité des relations devraient être supprimées des entités JPA (ou autre ORM).
Ce n'est pas parce qu'il y a une contrainte d'intégrité d'une table A vers une table B que le mapping de la table B dans A ou A dans B a un quelconque intérêt du point de vue de la gestion.

De manière générale (et toujours de mon point de vue et de mon expérience), le mapping devrait être centré sur la gestion CRUD des entités et pas du point de vue de l'utilisation dans une vue d'une application.
En gros, qu'une entité Facture est un Set de ses lignes paraît pertinent, on persiste Facture et avec les cascades, on persiste également ses lignes. Une ligne sans en-tête facture n'a pas de sens de même qu'une facture sans ligne n'en a.

Par contre, mettre dans une entité Societe des Set de Collaborateur, de Profil ou que sais-je n'a pas d'intérêt.
Si on veut afficher cette liste, on fera une requête sur Collaborateur (si le collaborateur n'inclut pas l'ID de sa société, se sera via une table de relation entre Societe et Collaborateur).

Bref, attention a se qu'on modélise dans les entités, on peut vite se retrouver à charger une multitude d'objets liés qui n'ont pas forcément d'intérêt à un point donné de l'application.

Pour ce qui est des relations bi-directionnelles, dans le contexte Facture/Ligne par exemple, l'entité Ligne aura également une relation ManyToOne vers son entité Facture pour des raisons plus techniques que logiques.
En effet, lorsqu'on va créer la facture, dans le cas où la clé est auto-générée, l'ID de la facture n'existe pas encore. Du coup, on ne pourrait pas rattacher les lignes à la facture.
En utilisant l'instance de la Facture dans la ligne, JPA commence par persister la facture (et met à jour l'ID) et ensuite persiste les lignes. Comme on a l'instance de Facture dans Ligne, on a maintenant l'ID de la facture.