Implémentation design pattern data mapper

Bonsoir,

Après avoir lu divers avis quant aux différents moyens d'implémenter la persistance du code métier, il apparaît que le pattern data mapper pourrait adresser certains problèmes des patterns gateway implémentés dans ZF.
Malgré tout, la description qui en est faite dans le livre de Martin Fowler et les divers exemples vus sur internet (comme celui dans le QuickStart guide du ZF) me laissent un peu perplexe.

Martin Fowler pose ainsi le postulat selon lequel le design pattern data mapper permet d'isoler le modèle à proprement parler de la couche utilisée pour la persistance. Le modèle n'aurait pas non plus connaissance du mapper qui l'utilise.
J'imagine donc que ce design pattern implique de manipuler des mappers au sein des contrôleurs et non plus des objets de la couche métier. Mais si je me trompe, n'hésitez pas à me corriger :)
Là où je suis particulièrement perplexe, c'est dans les relations entre les différents objets de la couche métier. En effet, comment récupérer des objets d'une classe qui en composerait une autre (ex. numéros de téléphone d'un utilisateur) si les objets de la couche métier n'ont pas connaissance de la couche mapper ? Et si l'on ne manipule que des mappers dans les contrôleurs, quel intérêt d'avoir une couche métier ?

Si vous avez de quoi m'éclairer concernant ce concept, je suis preneur.

Edit : en passant, il est possible que cette section ne soit pas la plus appropriée.

Si tu cherches des idées pour une implémentation, tu devrais regarder comment sont structurés les ORM tels que Propel ou Doctrine, c'est exactement ça qu'ils font.

Si je devais implémenter un tel mécanisme moi même, j'ajouterai une couche d'accès au données sous la couche modèle et j'équiperai ses classes de fabriques. Enfin, j'utiliserai le pattern décorateur pour la couche modèle.
Tu peux aussi faire des descripteurs en XML ou YAML (comme le fait Doctrine) pour unifier les classes de modèles au sein de l'ORM. Ce dernier sera alors capable de servir directement des classes modèles prêtes à l'emploi.

Personnellement j'ai réduit le problème à sa forme la plus simple: une classe abstraite Model qui implémente le CRUD et que doivent étendre les classes concrètes pour provisionner les requêtes SQL à effectuer par les méthodes CRUD. C'est assez simple et c'est efficace. J'ai par la suite créé une classe générique pour MySQL capable de lire les informations du MDD pour créer des objets génériques (au prix d'une requête supplémentaire).

Merci de ta réponse. Pour être plus précis, j'ai pu voir un example d'implémentation dans le Quickstart Guide du Zend Framework. Cela me laisse supposer qu'il y a eu des recherches effectuées dans ce sens chez les contributeurs du framework. Pour autant, l'exemple proposé me semble particulièrement survoler le problème, ce qui peut être gênant dans un guide de démarrage rapide.

Disons que je ne cherche pas particulièrement à implémenter mon propre système, mais que certains choix faits dans ZF me poussent parfois à pousser un peu plus loin ma réflexion (ce peut-être le cas des implémentations même des classes du framework ou, comme ici, les exemples proposés dans la doc). Je vais tout de même regarder du côté de ce que font les ORM existants pour voir leur façon de faire, et voir si je peux trouver un lien avec ce qui est écrit dans la doc.

S'il y a d'autres avis ou conseils, n'hésitez pas, il est toujours préférable d'avoir plusieurs points de vue :)

Personnellement, je me suis posé exactement les mêmes questions.
Je me suis dit "mais Zend n'est pas déjà censé faire sa??".
Et comme ce n'était pas le cas, et que refaire la roue toussa toussa, j'ai opté pour Propel, la mise en place était assez laborieuse, mais ensuite sa roule tout seul ;)
Sache que Propel génère tout seul tout tes objets modèle ainsi que le mapping etc... Il te suffit juste de spécifier la structure de tes tables dans un fichier XML.
En plus, si tu utilise MySQL, avec MySQLWorkBench et un plugin, tu peut générer automatiquement ce fichier XML (il faudra surement que tu modifie 2 ou 3 trucs, mais c'est mineur).

Doctrine permet également ce mode de fonctionnement à la différence que les fichiers de structure sont en YAML (YAML Ain't Markup Language). MySQL Workbench dispose également d'un plugin pour générer ces fichiers.

A vrai dire, ces outils me permettraient plus d'avoir des pistes qu'autre chose. Je préfère, probablement à tort, maîtriser les mécanismes mis en place au niveau structurel d'un projet.
De mon côté, j'ai bien quelques pistes qui ressortent pour répondre à ma problématique comme, en vrac :

- si on envisage un chargement global des objets, on pourrait faire le lien entre l'objet courant et ses composants directement à l’instanciation d'une classe,
- si on envisage un chargement "au fil de l'eau" (Lazy Loading), on pourrait lier des Proxy Objects qui se chargeraient d'utiliser les mappers correspondants lorsqu'on souhaiterait les utiliser pour la première fois.

Martin Fowler prenait l'exemple d'interfaces Finder, qu'implémenteraient les Mappers, qui seraient utilisées dans le Domain Model afin de restreindre volontairement la visibilité de la plupart des méthodes des Mappers. Cette approche me parait néanmoins inadaptée au fonctionnement de PHP (je me trompe peut-être, mais je crois qu'un contrat dans les paramètres d'une méthode n'empêche pas en PHP d'avoir accès aux méthodes non stipulées dans ce contrat). Par contre, on peut envisager des classes qui auraient des Mappers pour paramètres et sépareraient donc bien les Mappers du Model.

Je réfléchis encore aux différentes possibilités existantes ou à modifier, et tout avis est toujours bon à prendre ;)

Partant du postulat qu'une solution élégante est une solution simple à écrire et à comprendre, j'ai fait ça:

• https://github.com/bdelespierre/php-...odel.class.php
• https://github.com/bdelespierre/php-...odel.class.php
• https://github.com/bdelespierre/php-...ject.class.php (la spécialisation c'est cool :ccool:)
• https://github.com/bdelespierre/php-...base.class.php (pour faciliter tout ça)
• https://github.com/bdelespierre/php-...ator.class.php

Enfin on peut difficilement parler d'un véritable ORM, mais ça remplit son rôle: ça mappe des records sur des objets.