[Mapping] Structure d'une relation

**k4eve** · 27/04/2004, 10h36

Bonjour,

Concernant la persistance des objets et le mapping O/R, je me pose la question suivante sur la structure des classes à mapper :

Si j'ai à gérer un ensemble de clients et de contacts client est -il préférable de définir mes classes comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class Client{
   private String numeroClient;
   private String nomClient;
   private Collection contacts;
   ...
}
 
public class Contact{
   private String numeroContact;
   private String nomContact;
   ...
}

ou plutôt comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Client{
   private String numeroClient;
   private String nomClient;
   private String numeroContact;
   ...
}
 
public class Contact{
   private String numeroContact;
   private String nomContact;
   private String numeroClient;
   ...
}

Tout ça, sachant que j'aurais à gérer par la suite des devis pour lesquels il faudra préciser un client et un contact donné. La seconde hypothèse me semble pas très orientée objet.... et j'apprécierais votre avis !

**RanDomX** · 27/04/2004, 10h46

tout depends de ton modele relationnel et des relations entres tes entites ??

N-N ou 1-N?

Si un contact peut appartenir a plusieurs clients et un clients peut avoir plusieurs contacts, c du N-N et dans ce cas le mieux (3eme forme normale) c'est de definir une table qui stockeras tous les couples contact-client par clés primaires, donc trois tables

@+

**k4eve** · 27/04/2004, 10h50

1-N : 1 client, plusieurs contacts

**RanDomX** · 27/04/2004, 10h57

dans ce cas la premiere forme convient, du point de vue d'hibernate.

tu vas utiliser les "components" pour liers tes instances de contact a une instance de client.
Cependant tu as besoins d'un element commun, comme un id par exemple. Donc tu peux faire un mix des deux.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Client{ 
   private String numeroClient; 
   private String nomClient; 
   private Collection contacts; 
   ... 
} 
 
public class Contact{ 
   private String numeroContact; 
   private String nomContact; 
   private String numeroClient; 
   ... 
}

Au niveau de ta base par contre tu dois avoir deux tables:
CLient:
numeroClient
nomClient

Contacts:
numeroContact (clé primaire)
nomContact
numeroClient (comme clé foreign)

Ton component va jointer sur numeroCLient ds les deux tables.

@+

**k4eve** · 27/04/2004, 11h06

Par contre je viens de penser que j'avais vu que Poseidon (UML) proposait une classe n'utilisant pas une Collection mais un TreeSet. Quel intérêt ?

En fait, j'aimerais avoir l'approche la plus propre possible, c'est à dire la plus objet possible, et eviter d'avoir des classes inspirées d'une philosophie relationnelle... et c'est bien pour ça que j'ai besoin de votre avis !