Ne mélangeons pas tout, tu me parles de problèmes qui n'ont rien à voir avec PMO. Pour comprendre l'intérêt de PMO, il faut avoir un minimum de fondamentaux en OO.
On ne te parle pas de traitement de requête mais de transfert sgbd->php,
problème d'infra
soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin
Les problèmes que tu te poses ne sont pas liés à PMO mais à ton mcd, ou ton diagramme de collaboration/classes. Tu as mal conçu ton programme, de ce fait tes objets possèdent des attributs qu'il ne devraient pas posséder / manipuler.
soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur
PMO ne fonctionne pas comme ça
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
PMO n'est pas là pour pallier à des problèmes de conception. Si tu as une table avec 80 colonnes, c'est que t'as déjà un problème flagrant de MCD. De même PMO n'exclue pas la possibilité d'utiliser des colonnes. Tout dépend de l'implémentation de la class du parser SQL
gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
C'est ce que j'expliquais au dessus quand on utilise par un mapper comme PMO, on multiplie les lignes de code.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
Tu me fais rire : "les exigeants lecteurs de linuxfr". Ce fil de discussion découle du fait qu'un exigeant lecteur n'a lu que partiellement les doc.
Il y a des bonnes et des mauvaises critiques sur ce site, souvent on se retrouve confronté à des réactionnaires, mais ça n'en reste pas moins un média.
De là à dire qu'il faut recommencer un projet juste pour améliorer l'implémentation de méthode dans la class parser ...
[^] # Re: Mmmm, voyons voir...
Posté par Code34 . En réponse au journal PMO v 0.07 déjà. Évalué à -1.
On ne te parle pas de traitement de requête mais de transfert sgbd->php,
problème d'infra
soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin
Les problèmes que tu te poses ne sont pas liés à PMO mais à ton mcd, ou ton diagramme de collaboration/classes. Tu as mal conçu ton programme, de ce fait tes objets possèdent des attributs qu'il ne devraient pas posséder / manipuler.
soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur
PMO ne fonctionne pas comme ça
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
PMO n'est pas là pour pallier à des problèmes de conception. Si tu as une table avec 80 colonnes, c'est que t'as déjà un problème flagrant de MCD. De même PMO n'exclue pas la possibilité d'utiliser des colonnes. Tout dépend de l'implémentation de la class du parser SQL
gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
C'est ce que j'expliquais au dessus quand on utilise par un mapper comme PMO, on multiplie les lignes de code.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
Tu me fais rire : "les exigeants lecteurs de linuxfr". Ce fil de discussion découle du fait qu'un exigeant lecteur n'a lu que partiellement les doc.
Il y a des bonnes et des mauvaises critiques sur ce site, souvent on se retrouve confronté à des réactionnaires, mais ça n'en reste pas moins un média.
De là à dire qu'il faut recommencer un projet juste pour améliorer l'implémentation de méthode dans la class parser ...