Discussion :

[olivier252]

Bonjour,

Débutant en spécification JPA, je cherche à comprendre le mécanisme des objets inclus et des associations entre entités. Je suis entrain de suivre un tutoriel qui permet de réaliser une application de bibliothèque.
Il est dit dans le tuto ceci concernant la règle de fonctionnement des emprunts de livres :

"un Client peut effectuer un prêt de plusieurs Livres ; et comme un Livre a plusieurs exemplaires, il peut être emprunté par plusieurs Clients.
Chaque prêt ayant une date de début et de fin à prendre en compte, on se retrouve dans une association porteuse de propriétés. "

Voici un modèle UML à ma façon :



Une chose m'échappe dans ce schéma : est-ce qu'il faut comprendre qu'un prêt appartient à un seul livre ? Du coup ça devient contradictoire avec l'énoncé, non ?

Enfin une dernière question sur l'endroit où placer les annotations d'association : je vois dans certains exemples qu'elles sont tantôt au dessus des getters ou au-dessus des propriétés. Quelle est la différence ?

Merci beaucoup.

[PhilippeGibault]

Plusieurs questions dans ce post.

Pour la première (la classe prêt), tu as ce que l'on appelle (en UML) une classe d'association. Dans la base de données, cela se caractérisera par une table ayant une clé primaire sur deux id, chaque id étant une clé étrangère sur une des table (1 pour livre, l'autre pour client).

D'ailleurs, je recommande plutôt @EmbeddedId (Meilleur lien trouvé: https://blog.axopen.com/2013/11/les-...c-hibernate-4/ ).

Seconde question: Où mettre les annotations JPA?

Le mettre sur les méthodes ou les attributs, dans les 2 cas c'est correct. D'ailleurs, JBoss recommande, il me semble les méthodes. Spring, dans mes souvenir, recommandait les attributs.

En ce qui me concerne, je recommande les attributs. C'est un avis personnel.
Je trouve ça plus lisible et on sait d’emblée que l'attribut correspond à un champ dans la BDD, ce qui évite de rechercher le setter.

[olivier252]

Bonjour et merci pour votre réponse,

Du coup pur le modèle merisien, cela donnerait quelque chose comme ceci ?



Merci

[PhilippeGibault]

Non, il n'y a pas de clé étrangère dans livre (fk_id_pret) et client (fk_id_pret).

De plus, en parlant Merise, on a un MCD ou un MCD?
Le schéma ne correspond à rien.

Pour être plus précis, il y a deux possibilités.
1. Le client m’emprunte qu'une seule fois le livre. Dans ce cas, on a une double clé primaire (id_livre, id_client) qui sont des clés étrangères (sur id_livre de la table livre et id_client sur la table client).
2. Le client emprunte le livre plusieurs fois. Dans ce cas, on a un id unique dans la table pret, et une clé étrangère dans la table livre (fk_livre) et une clé étrangère dans la table client (fk_client).

Notez que j'ai différentié la clé primaire (id) de la clé étrangère (fk).

Notez aussi que pour utiliser JPA/Hibernate à bon escient, il faut de bonnes connaissances de la BDD relationnelle ainsi que de ce que l'on appellera la théori des ORM (JPA est un ORM).

C'est là où réside la difficulté de JPA/Hibernate.

[olivier252]

Merci encore,

du coup j'ai distingué le MCD du MLD selon vos explications pour essayer d'être plus rigoureux même si j'ai du mal à comprendre les 2 possibilités d'emprunt d'un livre une seule fois ou plusieurs fois.
D'ailleurs comment est-il possible d'avoir une clé étrangère livre dans la table livre et idem pour client ?

Voici ce que donne mon MLD, je crée une clé primaire composée de l'id de la table livre et client. Cela répond au fait que :
- 1 livre (qui existe en plusieurs exemplaires) peut-être emprunté au moins une fois
- 1 prêt est composé d'au moins 1 livre
- 1 prêt concerne un client
- 1 prêt concerne un livre

[OButterlin]

Pour répondre à ton problème de compréhension...
Un prêt concerne 1 instance de livre et 1 instance de client.
Un client peut emprunter plusieurs fois la même référence de livre vu qu'il existe plusieurs mêmes livres au sens d'une référence littéraire (ils auront chacun leur propre clé primaire, ce ne sont pas les mêmes instances).
Ce serait le cas d'une personne empruntant pour une autre bibliothèque (avoir une seule fois un livre à succès risque d'étaler un peu trop les emprunts des consommateurs, d'où l'intérêt d'en avoir plusieurs identiques).

Sinon, personnellement, je préfère les annotations sur les getter, ça évite de surcharger les propriétés de l'entity (ce que PhilippeGibault voit comme un avantage me paraît un inconvénient, mais comme il l'a dit, les 2 fonctionnent, c'est surtout une question de feeling ).
Par contre, il faut savoir qu'il y a une différence à l'exécution. Avec un AccessType PROPERTY (le défaut et recommandé), le chargement/mise à jour se fait via les getter/setter. En utilisant AccesType FIELD, l'opération se fait directement par les champs.

Enfin, personnellement toujours, je ne conseille pas de mettre les Set liés à la table de relation dans les entités Livre et Client, ça n'a pas d'intérêt du point de vue persistance et presque aucun intérêt du point de vue requête pour l'IHM.
Ça risque juste de ralentir les accès à un livre ou un client (sauf à mettre un FetchType LAZY).

Je préconise toujours de voir le modèle entity d'un point de vue "gestion" des tables et non du point de vue d'une fonctionnalité IHM (rechercher les livres empruntés par un client etc...).
Si on recherche les livres empruntés par un client pour une plage de dates données, il est beaucoup plus judicieux de faire un Query sur la table de relation, laquelle devrait avoir des relations ManyToOne vers les entités Livre et Client.
Du coup, via les instruction join fetch, on peut charger les informations liées dans la requête JPQL (select a from Pret a join fetch a.livre where ...)
L'autre intérêt de ce mapping serait de persister via l'entity Pret un livre et/ou un client inexistant (voir l'attribut cascade sur la relation ManyToOne) au moment de la demande (même si ça n'a pas forcément un intérêt dans ton cas, il faut savoir que c'est possible).