Discussion :

[Tourix]

Bonsoir à tous.

Je démarre actuellement un nouveau projet et en même temps j'apprends les design pattern avec le livre de Craig Larman: UML2 et le Design Pattern.
Etant encore novice dans le domaine, j'aimerais votre avis sur un cas simple pour être sûr de m'orienter dans la bonne direction.

Voilà le topo: je suis sur un projet web développé en PHP et pour l'instant je gère un cas basique: l'ajout d'un objet du domaine dans la base de données.

J'ai pour celà défini 3 couches:
- La couche IHM qui est donc l'interface utilisateur
- La couche domaine qui reprend les concepts de mon application
- La couche service qui regroupe des services non spécifiques à cette appli


Les "classes" logicielles impliquées sont les suivantes:
- FormulaireAjout (le formulaire en HTML)
- ObjetDomaine (le type de l'objet que j'ajoute)
- ObjetManager (le contrôleur qui reçoit le message de l'FormulaireAjout)
- DBManager (le singleton qui interface avec la Base de Données)


Ma question est simple: à qui affecter la responsabilité d'appeler DBManager?

J'ai choisit ObjetManager, les interactions sont donc les suivantes:

Code :

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

1
2
3
                ajouteObjet(nom, description)                enregistreObjet(nom, description)
FormulaireAjout ------------------------------> ObjetManager -----------------------> DBManager

Ma justification est que cela favorise le faible couplage. Mais dans la mesure où je ne n'instancie jamais ici d'objet de la classe ObjetDomaine, ça me semble assez bizarre...

Alors l'alternative serait de confier à ObjetDomaine la responsabilité de "s'enregistrer" mais là je me dis que si chaque classe du domaine doit avoir cette responsabilité, le couplage de mon application va en prendre un coup.


Du coup, en tant que débutant, je demande humblement votre avis sur la chose

Merci d'avance de votre aide

PS: désolé pour le "diagramme" en mode texte mais je n'utilise aucun outil uml pour le moment, je fais tout en esquisse

[TheLeadingEdge]

Bonjour,

Dans l'absolu oui, selon les pattern du GRASP, c'est bien le ''businessObject'' qui appelle l'objet service qui gère la BD. Maintenant je ne sais pas comment font les autres, mais pour moi sans 1 schema c'est chaud à répondre !
Tu pourrais t'inspirer utilement je pense des pattern MVC2 et DAO, qui correspondent (me semble-t-il) exactement à ce que tu veux faire (Web + BD)

A +

[Tourix]

Merci pour ta réponse rapide (et désolé pour la mienne qui est lente, je passe par une période avec peu d'accès au net)

Donc d'après ce que tu me dis, et les références que tu me donnes, ça devrait être à peu près bon ce que je fais.

A la différence que contrairement à ce schéma (qui si j'ai bien compris illustre MVC2)


Ce n'est pas ma couche domaine qui interagit avec la base de données mais ma couche "service"

J'ai en effet une application en 3 couches:

IHM: pages web et fichiers swf
Domaine: tout ce qui concerne l'application en elle-même
Service: les services externes non spécifiques à cette application (interaction avec la BDD, création/lecture de fichiers xml...)


J'ai donc IHM qui envoie un message à Domaine (un contrôleur en fait) qui appelle Service (le DBManager)

[ego]

Si tu as une vision objet des choses, tu dois passer un objet à ton DBManager et non les valeurs des attributs de l'objet que tu n'as pas créé.
Donc ton ObjectManager doit créer l'ObjectDomaine puis le passer au DBManager qui le stockera dans la base.
Il faut que tu pense que par exemple, au niveau de l'IHM, les données sont peut être saisies dans un format qui n'est pas celui directement attendu par ton objet du domaine (penses aux dates par exemple). Il faut donc dans un premier temps créer l'objet avec les attributs tels que saisis dans l'IHM et ensuite passer cet objet aux autres objets qui vont avoir à le traiter (dans ton cas le DBManager). Ce n'est pas à ces autres objets de savoir comment reconstruire ton ObjectDomaine en fonction de la manière dont il a été défini au niveau IHM.

[Tourix]

Je comprends bien ta vision des choses, mais cela n'ajoute-t-il pas un couplage entre ObjetDomaine et DBManager qui pourrait être évité?

Si traitement il doit y avoir entre l'IHM et le DBManager, l'ObjetManager s'en charge, il a pour responsabilité de fournir les données à enregistrer au bon format.

Ceci dit je suis d'accord avec ce que tu dis et je suis donc partagé entre Forte Cohésion (passer une instance d'ObjetDomaine à DBManager) et Faible Couplage (ObjetManager n'envoie que les données à enregistrer dans le bon format)


En tout cas merci pour ta participation à la discution

[ego]

Mais il y a forcément un couplage entre la partie accès aux données et les objets créés à partir de ces données. Rien de choquant ici.

[Tourix]

oui, mais en fait je pensais l'éviter car j'en vois pas l'intérêt, puisque je peux m'en passer.

Et donc selon toi, une meilleurer façon de faire serait de faire créer l'ObjetDomaine par l'ObjetManager et le passer en paramètre au DBManager?

(illustration en pseudo code)

Code :

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

1
2
3
4
5

// dans une méthode de ObjetManager
$objet_domaine = new ObjetDomaine($parametres....);
DBManager::getSingleton()->saveObjet($objet_domaine);

(Mon application est en PHP)

[ego]

oui
Ce n'est pas parce que tu te contente de passer les "attributs" de ton objet sans passer ton objet que tu as un couplage faible. Tu as même un couplage plus "chiant" à gérer car dès que tu ajoute un attribut à ta classe tu dois modifier l'interface de ton DBManager. En passant un objet, tu n'as pas ce problème (tu dois quand même modifier le code "SQL" du DBManager mais pas son interface).