Discussion :

[jecomprendsrien]

Bonjour,

dans le livre Java que je suis en train de lire comme sur beaucoup d'exemples sur le net également, je remarque souvent l'utilisation d'une entité embarquée (avec @Embeddable et @Embedded). L'exemple type est celui d'une personne embarquant une entité adresse et formant donc une table unique personne en bdd.

Un exemple ici

L'intérêt est apparemment de pouvoir utiliser l'entité adresse dans une autre classe. Mais dans quel cas cela peut il arriver ? Et pourquoi ne pas directement récupérer l'entité personne et via les accesseurs accéder à son adresse ?

Je n'arrive pas à comprendre l'intérêt des entités embarquées

Quelqu'un peut il m'expliquer ?

Merci

[Aure7780]

L'interet, c'est que tu travailles sur de la persistance de données.

Les classes annotées par @Entity ont donc pour finalité d'être persistées en base de données.
Tous les membres de cette classes deviennent donc des champs possibles en base. JPA gère tous les types par défaut (int, boolean, String, ...) pour créer les champs.

Or si tu lui spécifier comme membre un Classe à toi, JPA ne sais pas comment créer ce champ.
Il incombe au développeur de faire un choix, comment stocker cette donnée :

Prenons le cas de l'entité Personne qui contient un membre Adresse :
Choix 1 : Adresse est annoté par l’annotation @Entity, chaque entité aura sa propre table en base soit 2. Donc pour avoir accès à l'Adresse d'une personne, il faudrait faire une relation entre les 2 tables (entités) : @ManyToMany, @OneToMany, ...
Choix 2 : Adresse est annoté par l’annotation @Embeddable, seul l'entité Personne sera persisté en base. En précisant l'annotation @Embedded sur le membre Adresse de la classe Personne, ont dit à JPA : "intègre les champs de cette entité (Adresse) à l'intérieur de l'entité en cours (Personne)".
Avec @Embeddable tu n'as donc qu'une seule table en base qui contient les champs des 2 classes.

Cela permet d'améliorer le modèle objet sans pour autant modifier le comportement en base...

[jecomprendsrien]

Bonjour et merci de ta réponse

Cela permet d'améliorer le modèle objet sans pour autant modifier le comportement en base...

En quoi stp...?

J'ai bien compris le principe des annotations, des relations etc...par contre je vois pas en quoi cela simplifie les choses d'utiliser une classe embeddable.
En effet, le but est de créer une seule table donc pourquoi scinder en 2 classes côté JPA ?

Le seul intérêt serait d'utiliser la classe Adresse dans une autre classe JAVA mais je vois pas dans quel contexte cela serait utile. Quand bien même cela serait utile, un simple personne.getRue(), personne.getNumero() etc ferait l'affaire...non ?

Il doit y avoir un intérêt...mais je vois pas

[Philippe Bastiani]

Il doit y avoir un intérêt...mais je vois pas

D'un côté tu fais de l'objet avec JPA.. de l'autre un modèle relationnel pour la base de données... Bref, 2 modèles de données différents avec des contreintes et des objectifs qui peuvent s'opposer... Côté Java ton objet adresse est un objet métier qui peut te servir pour ton entité Personne où à toute autre objet de ton modèle indépendamment de Personne. Côté BDD, si ton entité adresse n'est utilisée que dans ton entité Personne tu peux souhaiter l'intégrer directement dans Personne... ici, dans ton modèle BDD, tu perds en design objet mais tu peux y gagner en performance et/ou en conception pour tes requêtes.
a+
Philippe

[jecomprendsrien]

Bonjour Philippe,

Côté Java ton objet adresse est un objet métier qui peut te servir pour ton entité Personne où à toute autre objet de ton modèle indépendamment de Personne

certes, mais ce que je comprends pas c'est quel intérêt a t-on à avoir d'un côté soit :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
String rue = personne.getAdresse().getRue();

dans le cas donc d'une entité Adresse embarquée ou bien :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
String rue = personne.getRue();

dans le cas d'une entité Personne n'embarquant pas de classe Adresse ?

Il est vrai que le fait de pouvoir récupérer une adresse directement d'une personne peut apporter plus de souplesse mais finalement quel intérêt puisque le but d'une entité est d'être persistée en base et donc il nous faudra bien peupler à un moment ou un autre tous les champs de notre entité personne.

Merci de vos éclairages encore

[Philippe Bastiani]

Côté Java/JPA: L'interêt
- c'est de pouvoir conserver un modèle objet; et, non pas un modèle à plat où tu ressemble tous tes attributs dans un même objet.
- c'est de pouvoir détacher l'objet adresse de son conteneur,
- etc

Côté BDD/relationel: c'est de s'affranchir de cette conception objet pour avoir un modèle relationnel ! dans ton exemple, si le cycle de vie de ton adresse est totalement lié à son contener... tu peux ressembler les 2 tables en une.

a+
Philippe