Discussion :

[novayl]

Bonjour,

J'ai un petit soucis là, j'ai du mal à mapper le problème suivant (j'dois mal m'y prendre)

Prenons 3 entités (c'est un exemple, mais l'idée est là) :
Personne
Peintre
Carreleur

Un peintre est une personne.
Un carreleur est une personne.
Une personne peut être un peintre ET un carreleur.
Une personne peut aussi n'être rien du tout (juste une personne, sans "rôle" particulier)

Illustration :

Code :

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

1
2
3
4
5
6
7
8
 
table personne     table peintre     table carreleur
id                      id                     id
1                        1                      2          
2                        4                      4 
3                                               5                      
4
5

Comment je mappe ça avec JPA ?

J'ai essayé de la manière suivante, mais c'est pas bon, puisque chaque entrée est unique (un peintre ne peut pas être un carreleur) :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class Personne extends AbstractEntity
 
@Entity
public class Peintre extends Personne
 
@Entity
public class Carreleur extends Personne

Bien évidemment si j'essaye de faire ça, c'est parce que la personne a ses méthodes propres, le peintre aussi et le carreleur également...

Mais j'm'y prends ptete mal, y'a ptete un design pattern qui réponds mieux que l'héritage à ce problème ?

[Chabanus]

Tu dois placer cette annotation avant la définition de la classe Personne

Code :

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

@MappedSuperclass

Essayes de réviser tes cours d'héritage

[novayl]

C'est pas ça que j'essaye de faire.
Par correction, j'ai quand même essayé, au cas où. L'annotation @MappedSuperclass est utile notamment pour définir une classe utilitaire comme je le fais avec la "AbtractEntity".

Je cite la doc d'hibernate à ce sujet :
This is sometimes useful to share common properties through a technical or a business superclass without including it as a regular mapped entity (ie no specific table for this entity). For that purpose you can map them as @MappedSuperclass.

Ce n'est pas ce que j'essaye de mapper, puisque je veux inclure la classe Personne. Une personne peut très bien exister dans mon système sans avoir les propriétés additionnelles d'un peintre ou d'un carreleur. Et c'est bien ça mon problème, j'essaye de stocker dans Personne toutes les propriétés d'une personne, puis dans les tables filles, toutes les propriétés additionnelles d'une personne quand en plus, elle "est" un peintre.

Note : j'ai pris un exemple trivial, ce n'est bien évidemment pas le cas réel.


L'autre solution expérimentée est de ne pas avoir d'héritage. Dans ce cas, les tables "carreleur" et "peintre", sont de fait des tables de liaisons many-to-many avec par exemple une table "ouvrage".
Ce qui me chagrine un peu dans ce cas de figure, c'est que je perds la notion "est-un". Dans mon cas justement, elle est très importante.

[Patriarch24]

Un peintre est une personne.
Un carreleur est une personne.
Une personne peut être un peintre ET un carreleur.
Une personne peut aussi n'être rien du tout (juste une personne, sans "rôle" particulier)

Ce que tu décris là ce n'est pas de l'héritage. "Carreleur" et "Peintre" doivent plutôt être des rôles (métier ?), associés à une personne ; chaque personne a un ou plusieurs rôles (par exemple dans ta classe Personne, tu auras une liste de rôles).

[novayl]

Oui c'est un peu ça. Sauf que là, j'ai pris un exemple trivial, qui n'a rien à voir avec le cas réel.

Dans mon cas, un Carreleur EST une personne, une personne "étendue".
Pour être clair, ma personne peut avoir près de 10 rôles en même temps dans la base. Sauf que chacun de ces rôle est une entité à part entière. Chaque rôle à des associations et des méthodes qui lui sont propres.

Je conçois bien que l'héritage n'est pas le plus adapté, j'essaye simplement de remplacer la solution bancale actuelle par quelque chose de plus propre.

Note pour plus tard : ne plus donner des exemples pseudos-concrets

[Patriarch24]

Je conçois bien que l'héritage n'est pas le plus adapté, j'essaye simplement de remplacer la solution bancale actuelle par quelque chose de plus propre.

À mon avis, il faudra éviter l'héritage. L'exemple n'étant pas correct, je pourrai pas te donner d'autres pistes.