Discussion :

[k4eve]

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]

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]

1-N : 1 client, plusieurs contacts

[RanDomX]

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]

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 !

[RanDomX]

C'est une liste triée (TreeXXX) et sans Doublons (Set).

Tu generes ton code et tu remplaces avec ce que tu veux.

@+

[k4eve]

OK, grand merci !