Discussion :

[Mandotnet]

Bonjour,

j'ai une table contact et une table catégorie. un contact est toujours associé à un seul ID de catégorie.

au niveau couche de données, j'ai donc implémenté les "CRUD" (create, read,update,delete) de la table catégorie et contact, ce sont des appels aux procédures stockées, au niveau implémentation je ne fais juste que remplir les paramètres et j'exécute la commande.

au niveau de la couche business/métier, je fais un mapping OR, cad je représente mes entités sql sous la forme de classe objet. chacun des objets fait alors appel à la couche de données pour la persistance.

jusque là, pourriez vous me dire si je me trompe .?

Ici je me retrouve avec une classe objet qui aura un champ _idCategorie de type INT... mais certaines tables sont entièrements constituées de clefs étrangères, est-il alors également nécessaire de mapper ces tables sql, et de me retrouver avec des objets qui ne contienne que des champs INT ? je n'ai pas poussé la réflexion encore assez loin sur ce sujet, alors je vous remercie par avance de m'éclairer la dessus

Cordialement, :-)

[kungfoo]

au niveau de la couche business/métier, je fais un mapping OR, cad je représente mes entités sql sous la forme de classe objet.

Oui et non, les deux modèles devraient en fait être développés en parallèle selon moi. Ensuite, tu fais le sale boulot de mapping OR, mais tu ne peux pas simplement créer une classe pour chacune des tables, le modèle objet doit être... un modèle objet.

Prennons ton exemple :

Ici je me retrouve avec une classe objet qui aura un champ _idCategorie de type INT...

Tu auras en fait une classe Contact et une classe Catégorie qui ne contiennent évidemment pas de clés primaires et étrangères. La classe Contact contiendra par exemple un attribut de type Catégorie. La classe Catégorie pourrait contenir un tableau de Contacts.

Lorsque vient le temps de faire appel par exemple à ta méthode create de Contact, pour créer le Contact, c'est là que tu devras récupérer la clé primaire de la catégorie associée et l'insérer dans la table Contact avec ta nouvelle entrée. Ne pense pas en termes de clé étrangères, primaires... pense plutôt en terme d'attributs et de visibilité d'une classe à l'autre.

Je n'ai pas l'impression d'avoir été très clair mais bon ... ton modèle objet doit être un modèle objet et non simplement un modèle dérivé de ton modèle relationnel.

[Mandotnet]

D'accord, je te remercie pour ta réponse

je vois ce que tu veux dire. Je ne devrais jamais avoir de "clef étrangère" sous forme de Id dans mon modèle objet, mais plutot une référence/Attribut vers une classe/objet associé à cette clef.

Ceci me parait effectivement plus propre et plus lisible.

De la même manière, si par exemple mon contact est en relation n-aire avec une entité contrat, alors cela se traduira par une collection/tableau de contrat dans les attributs de mon contact ?

si je me trompe dis le moi :/
Merci

[kungfoo]

De la même manière, si par exemple mon contact est en relation n-aire avec une entité contrat, alors cela se traduira par une collection/tableau de contrat dans les attributs de mon contact ?

Exactement. Si on prend l'exemple d'ajout de nouveaux contrats à un contact.

À chaque nouveau contrat créé, tu vas créer une instance de contrat que tu vas ajouter à la liste de contrats de l'instance du contact associé.

Lorsque vient le temps de sauvegarder ton contact, au niveau de ton mapping, tu vas parcourir la liste des contrats qui lui sont associés et les insérer dans ta base de données.

C'est un peu plus de boulot au niveau du mapping que ce que tu avais proposé initiallement mais ça en vaut le coup.

Un petit pattern, peut-être un peu lourd si tu ne pense pas migrer vers un autre moyen de persistance des données, mais quand même toujours bon à connaître, DAO.

[Mandotnet]

Parfait, merci pour ton aide

[Mandotnet]

J'ai tout de même encore un point sur lequel j'ai des doutes, pour faciliter la chose, je joins ci-dessous le shéma de la BDD pour notre exemple :



Nous avons cette fois des contacts, des services et la table des abonnements qui correspondent aux services que les contacts prennent.

Si je reprends ce que nous avions dit, alors au niveau de mon objet métier Contact, j'aurai eut un champ qui serait une collection de services. Néanmoins dans le cas ci-dessus je n'aurai pas l'information concernant la date d'abonnement ni celle de rupture... Dans ce cas devrais-je avoir un champs qui serait plutot un tableau d'abonnement ? Mais comment serait modélisée ma classe Abonnement ? (sans l'objet Contact ?)

J'en arrive à me demander si je ne devrais juste me contenter de mapper la table Contact et de ne pas ajouter d'information relative aux abonnements et services. (mais pour autant, cela ne correspondrait pas à la modélisation UML que je serai amené à faire ..)

Merci pour votre aide (et désolé d'insister encore)