[MVC]Implémentation

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, :-)

Citation:

---

Envoyé par Mandotnet

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 :

Citation:

---

Envoyé par Mandotnet

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 :oops: ... ton modèle objet doit être un modèle objet et non simplement un modèle dérivé de ton modèle relationnel.

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

Citation:

---

Envoyé par Mandotnet

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.

:mouarf:

Parfait, merci pour ton aide ;)

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 :

http://www.developpez.net/forums/att...1&d=1176119503

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)

Rebonjour!

Bon pour commencer, je n'arrive pas à voir ta pièce jointe :oops:

Alors voilà en fait, au niveau de ton diagramme UML, ton abonnement pourrait prendre la forme de ce qu'on appelle une classe d'association entre contact et service, elle n'a de raison d'être que lorsqu'il existe un lien entre ces deux entités.

Je m'explique, pour chaque liaison qui existe entre un contact et un service, c'est à dire un abonnement, on va créer un lien entre ce contact et ce même service. En utilisant une classe d'association, tu pourras conserver les informations relatives à l'abonnement dans l'association qui relit les deux, petit diagramme UML en pièce jointe!

Au niveau de l'implémentation, ça va dépendre de la visibilité qu'il te faut mais ça pourrait prendre la forme suivante :

Le contact va contenir une liste d'abonnements, chaque abonnement sera relié à un seul et unique service (c'est la façon que je le vois) et donc contiendra un attribut de type service. Tu pourrais aussi avoir une liste d'abonnements associés pour chacun des services si par exemple tu as besoin de voir qui est abonné à un service donné.

Tu peux voir ça comme une super association qui conserve de l'information :)

J'espère avoir été à peu près clair :aie:

Merci kungfoo, c'est très clair.

Je me rends davantage compte que tout cela dépends un peu des besoins et comme tu le dis, de la visibilité que l'on souhaite avoir.

Ta solution me convient et je te remercie pour le temps que tu m'as accordé ;-)