MVC | DAO dans la pratique

Bonjour,

Je rencontre souvent le problème sur la manière de récupérer des données complexes d'une base de données avec toujours l’opposition performance / maintenabilité.
Du coup je me renseigne sur le modèle MVC et plus précisément sur DAO qui me plaît dans la théorie mais qui, dans la pratique, garde les mêmes problèmes.
J'aimerais donc avoir vos avis éclairés sur le problème pratique suivant.

En partant du modèle suivant : http://www.odi.ch/prog/design/php/guide.php (section Use Value Objects (VO) et Use Data Access Objects (DAO)).
Chaque table de la BDD possède une structure qui définie tous et uniquement les champs de la table (VO).
Chaque table de la BDD possède une classe qui permet de charger, supprimer et sauvegarder une ligne de la table (DAO) à partir de l'objet VO.

Jusque là, le système est carré, et ça fait plaisir.
Pour gérer des blogs et des cas simples de ce genre, pas de soucis.

Le problème arrive dans dans le cas où on doit traiter un grand nombre de données qui sont croisées dans plusieurs tables de la base, on a deux solutions :
- le plus directe et le plus performant, je pense : une grosse requête qui renvoi tout d'un coup, mais plus possible d'utiliser nos classes DAO et VO (code gtéré dans le conrôleur).
- le plus "propre" : on passe quand même par les DAO et VO mais on exécute du même coup beaucoup BEAUCOUP BEAUCOUP plus de requêtes.

Dans mon cas, j'utilise tout le temps la première méthode. Mais je réfléchis souvent comment le faire avec la seconde méthode (sans succès jusqu'à présent).

Je vous remercie d'avance pour vos remarques liées à vos propres expériences et techniques.

Salut,

A la lecture de ton lien, je ne vois pourquoi tu ne pourrais pas créer autant de DAO et de VO que nécessaire pour chaque grosse requête ^^

Citation:

---

For n-to-n relationships create a separate DAO (and even a VO if the relationships has additional properties) for the relation table.

---

Houlà, ce site est vieux, très vieux. Beaucoup de ce qu'il montre est obsolète et ne représente plus le PHP d'aujourd'hui. À ne pas mettre entre les mains de débutants :-)

Sinon, tu peux regarder ce que fait Doctrine, qui implémente le pattern Data Mapper (l'équivalent du DAO en terminologie fowlérienne) avec un Unit of Work. Tu as ici une revue intéressante mais incomplète de ce qu'il fait en coulisse. Sinon, une recherche sur Data Mapper et Unit of Work (qui résoud le problèmes des multiples requêtes) t'aidera.

Je vais me renseigner sur Data Mapper, merci.

Pour répondre à rawsrc, le problème ne vient pas du fait de créer une classe pour chaque relation, mais plutôt de la bonne pratique pour des cas complexes.
Par exemple, si on veut afficher toutes les news avec la catégorie (une news possède une seule catégorie).
- Comment je le gère actuellement : dans la contrôleur, une requête avec liaison sur les deux tables et j'affiche. Le problème, l'accès aux données se fait au niveau du contrôleur.
- Pour respecter l'accès aux données, il faudrait utiliser les objets DAO et VO, mais le nombre de requêtes serait plus important et en général je préfère faire le moins de requête possible.

Le cas est extrêmement simple, mais au final ça reflète un cas complexe qui mériterait une étude plus approfondie.

La question serait donc, où et comment faut-il gérer cette requête ?
- Au niveau de l'objet métier, ça parait assez évident à première vue.
- L'objet NewsDAO doit-il posséder une méthode qui renvoi une liste d'objet NewsDAO, puis pour chaque News, demander l'objet CategorieDAO ? De cette manière, la séparation est bien faite, mais au niveau performance, on va exécuter autant de requête sur la table catégorie que l'on va avoir de news. Est-ce une très mauvaise idée (en gardant en tête des cas où il y aura des milliers de lignes croisées avec 4 ou 5 tables) ? Est ce une bonne pratique au dépend des performances ?
- Ou alors, notre objet métier doit-il exécuter une requête renvoyant tout le résultat (donc avec liaison), puis initialiser les objets DAO (ou VO) avec cette requête ? Pour moi il s'agirait de la meilleur méthode, le problème est que pour initialiser l'objet VO, on ne sait pas forcement si on aura tous les champs dans la requête (ou alors des champs de même noms dans plusieurs tables), ce qui le rend donc potentiellement impossible sauf de respecter des règles contraignantes.

Salut,

C'est clair que l'accès aux données via SQL directement dans le contrôleur, c'est moyen...
Comme tu le soulignes, ce genre de requête devrait être logée dans le modèle.

Dans ce genre de cas, soit tu fais appel à un ORM qui va te rendre tout ça dynamique, soit tu procèdes autrement en évitant de figer les DAO dans le marbre.
En PHP il est possible de récupérer tout sous forme de tableau ce qui permet de préserver la souplesse.
Après que tu fasses : $record->property; ou $record['property'], c'est pareil.
En terme de performances, il est bien plus rapide de rapatrier une colonne ou deux supplémentaires dans un jeu de données même si elle ne serviront pas que de faire un tas de requêtes pour s'en affranchir.
Donc, je ferais une vue qui croiserait les tables ce qui te permettrait de paramétrer le rendu au plus près.

Citation:

---

Envoyé par rawsrc

Après que tu fasses : $record->property; ou $record['property'], c'est pareil.

---

C'est exactement ce cas, mon côté pratique me fait utiliser $record['property'], mais mon côté puriste C++ aimerait pouvoir écrire $record->property;.

Évidement je ne parle pas juste de l'écriture, mais d'utiliser la logique objet.