[PHP 5.3] [MVC] gestion de la vue / rendu via classe et toString [Résolu]

[laville]

Bonjour,

Je suis aujourd'hui confronté à un débat avec certains de mes collègues sur la meilleur façon d'implémenter la partie MVC dans ma société.

Cette problématique est au niveau de la vue et de classes métiers (qu'ils considèrent être lié au controller).

Prenez l'exemple de l'implémentation en PHP du fameux jqgrid. Nous avons donc là deux écoles :
- la première disant que tout ce qui est à la vue doit être écrit dans la vue (ou à la rigueur dans un helper de vue mais là dessus pas encore certain)
- la seconde, disant que dans la vue nous pouvons faire un simple 'echo" de l'objet qui utilisera la fonction _toString() qui est pour moi là pour ca.

Effectivement la seconde solution lie quelque peu la partie vue et métier.
Mais en mon sens, la vue dit bien qu'il faut afficher un tableau, et c'est la classe métier qui va elle générer comme il se doit le tableau.

Pour la seconde, aucune génération en PHP, pas de classe PHP manipulant le Tableau, tout est dans la vue.


Ce problème peut se retrouver aussi dans d'autres composants, à savoir le Zend_Form qui propose des décorateurs permettant la génération via un simple echo dans la vue d'un formulaire pouvant être complexe. La dessus aussi bien entendu ils sont contre car ils considèrent que cela n'est pas géré dans la vue et donc que l'on est pas MVC.


Merci donc de prendre le problème dans son ensemble et de ne répondre que si vous avez un avis très conceptuel de la chose, le but n'étant pas d'avoir des opinions personnelles, mais plutôt conceptuelles sur les bonnes pratiques à ce niveau là.

Merci d'avance pour vos lumières sur ce point

[MaitrePylos]

PHP n'est pas là pour manipuler le HTML.
On doit séparer le code PHP de HTML, donc la vue doit rendre uniquement le contenu, d'ailleurs le code PHP d'une vue ne doit permettre que de faire des parcours tableaux ou echo de variables, le tout bien entendu géré dans les controller et model.

Utilisateur intensif de ZF, je suis d'accord (heu oui c'est personnel) avec le fait que Zend_Form n'est pas MVC, je ne l'utilise jamais (trop d'heures perdue pour un simple formulaire).

Je me rangerais donc du côté de tes collègues !

[rawsrc]

Envoyé par MaitrePylos

PHP n'est pas là pour manipuler le HTML.

Euh, je pense qu'il ne faut pas être aussi restrictif. Il ne faut pas quand même oublier qu'une page web ce n'est que du texte. Donc ce n'est pas un non sens que d'utiliser PHP pour produire du texte à la volée, texte avec un formatage particulier certes, mais du texte quand même.
Après, séparer le HTML du PHP c'est une bonne pratique qui est à recommander fortement.

Envoyé par laville

Je suis aujourd'hui confronté à un débat avec certains de mes collègues sur la meilleur façon d'implémenter la partie MVC dans ma société.

Bienvenu dans l'éternel débat concernant les interprétations du concept MVC.

La place de la vue est en bout de chaîne. La vue ne fait rien d'autre que générer du code qui sera envoyé au client à partir des paramètres qui lui sont spécifiques. Le code à générer peut être du HTML, XML, PDF....
Dans notre framework, une vue peut faire appel à d'autres vues mais à aucun autre type de composant. Par corrélation, on ne dérive pas les vues les unes des autres (pas de décorateur), les vues se résument à des briques individuelles assemblables les unes aux autres pour composer des rendus très complexes. Enfin, une vue ne fait que générer du code et rien d'autre (en particulier aucun envoi).

[laville]

PHP n'est pas là pour manipuler le HTML.
On doit séparer le code PHP de HTML, donc la vue doit rendre uniquement le contenu, d'ailleurs le code PHP d'une vue ne doit permettre que de faire des parcours tableaux ou echo de variables, le tout bien entendu géré dans les controller et model.

Effectivement je suis d'accord, la grande théorie veut cela mais souvent on fait au final :
- du contrôle de droit
- on implémente des règles métier selon tel ou tel paramètre
- etc.

Pour ma part, je suis pas en désaccord avec mes collègues, mais je serais plus souple. Zend_Form n'est pas réellement MVC (même s'il a des helper de vue qui font la génération HTML) mais pour moi il correspond à un besoin (et une fois le système compris cela va réellement bien crois moi, mais faut le comprendre...).
Il en va de même pour d'autres composants la jonction entre Vue et Controller est infime et complexe car :
- qui gère les inclusions de scripts dont on a besoin dans la vue ?
- qui gère l'affichage ou non de portions de codes ? Est-il nécessaire de faire plusieurs vues gérées par le controller pour réellement respecter le concept MVC ?

Si on veut du vrai MVC, avec une vue ne gérant que la présentation des données, on en revient inévitablement à une multitudes de fichiers appelés ou non par le controller... ou on crée des helper de vue utilisés par le Zend_Form.

Pour moi il y a une notion entre respect à 100% du concept et gain en temps (par exemple, peut-on dire que Smarty, générateur de template HTML assez reconnu, appartient à la vue ? Pour moi non il correspond aux helper de vue).

Mais malgré tout, je reste d'accord avec une personne qui me dit que conceptuellement un MVC, pour la partie vue c'est purement de la présentation. Après en réalité, il faut bien enrober cela car sinon cela nous ferait plus de travail / fichiers à maintenir que de gain réel apporté.

Bienvenu dans l'éternel débat concernant les interprétations du concept MVC.

Ah ça.... oui mais c'est ce qui est plaisant, si cela est fait intelligemment, le partage des opinions fait que chacun avance (on en apprend tous tous les jours et encore heureux, on revoit nos opinions sur certaines méthodologies et raisonnement, etc.).

La place de la vue est en bout de chaîne. La vue ne fait rien d'autre que générer du code qui sera envoyé au client à partir des paramètres qui lui sont spécifiques. Le code à générer peut être du HTML, XML, PDF....

Oui, mais exemple avec la génération csv etc. tu pourrais généraliser cela avec une aide de vue qui automatise cela au lieu de le duppliquer, pourtant c'est bien une classe qui va te le générer donc :
- gain important + réutilisabilité + maintenabilité contre :
- duplication de la fonction dans chaque vue

Au final, il semblerait qu'on soit arrivé à un consensus au niveau des aides de vue. Une classe, pour quelque rendu que ce soit (HTML, JavaScript, etc) doit passer par des helper.

Il me semble que ce soit une bonne pratique mais surtout un bon compromis entre respect des règles MVC et optimisation / réutilisation du code.

Qu'en pensez vous ?

[rawsrc]

Envoyé par laville

Oui, mais exemple avec la génération csv etc. tu pourrais généraliser cela avec une aide de vue qui automatise cela au lieu de le duppliquer, pourtant c'est bien une classe qui va te le générer donc :
- gain important + réutilisabilité + maintenabilité contre :
- duplication de la fonction dans chaque vue

Au final, il semblerait qu'on soit arrivé à un consensus au niveau des aides de vue. Une classe, pour quelque rendu que ce soit (HTML, JavaScript, etc) doit passer par des helper.

On n'utilise aucun helper (au sens commun) et on ne duplique rien, dans notre framework chaque vue est une classe.

Voici un squelette de la gestion de cette problématique :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php
 
// 1ERE APPROCHE
$blk = new BLK_CreateFileCsv(); // la vue est une classe
$blk->params()->setData(...array...); //paramétrage
$blk->render();
 
 
// 2EME APPROCHE
// autres moteurs de rendu
class BLK_CsvEngine { }
class BLK_XlsEngine { }
class BLK_PdfEngine { }
 
class BLK_CreateFile {
 
   function params() { }
 
   function render() {
      if ($this->params()->format() === 'csv') {
         $blk = new BLK_CsvEngine();
      }
      else
      if ($this->params()->format() === 'xls') {
         $blk = new BLK_XlsEngine();
      }
      else
      if ($this->params()->format() === 'pdf') {
         $blk = new BLK_PdfEngine();
      }
      // on passe les données au moteur de rendu
      $blk->params()->setData($this->params()->data());
      $blk->render();
   }
}
 
// code qui pourrait être dans un contrôleur
$blk = new BLK_CreateFile();
$blk->params()->setFormat('csv');     // paramétrage en provenance du client
$blk->params()->setData(...array...); // paramétrage en provenance du modèle
$blk->render();
 
?>

Comme tu peux le constater, on assemble les vues et on ne fait rien d'autre. A la rigueur, organisé ainsi, on peut considérer que chaque vue est son propre helper. A toi de bien découper tes vues afin de pouvoir les réutiliser au maximum. Au final, tu ne fais que manipuler des classes pour tout : contrôleurs, modèles et même pour les vues.

[laville]

Envoyé par rawsrc

On n'utilise aucun helper (au sens commun) et on ne duplique rien, dans notre framework chaque vue est une classe.

Effectivement, mais dans le cas que tu me montres, helper (qui est une classe) ou ce que tu as écris, même s'ils ne portent pas le même nom (et qu'ils n'ont pas à 100% le même rôle) la logique reste la même.

Un helper de vue comme le headScript de Zend ne gère que la partie scripts, et faire une classe de gestion de scripts reviendrait au même enfin arrête moi si je me trompe (ou si je n'ai pas compris ce que tu voulais dire).

Un exemple :

Code :

1
2
3
4
<?php
$this-> headScript() -> appendFile($this->baseUrl().'/js/action.js');
?>
<button name="back" onclick="fonctionDansFichierAction()" >Retour</button>

Dans l'exemple, mon helper de vue a exactement le même but que ta classe
Donc séparation mais utilisation de classes (helper, classes de rendues, Smarty, etc.) qu'ils mettaient au départ comme appartenant à un controller (classe = C ou M et non V) mais à mon avis et d'après ce qui se dit au final, il y avait une incompréhension au niveau de classes de rendu (quelque soit leur rôle).

[s.n.a.f.u]

Vous pouvez éventuellement voir l'évolution de mentalité pour ce qui concerne la Vue dans le Zend Framework après les retours d'expérience sur la version 1.

C'est édifiant :

http://framework.zend.com/wiki/displ...ilestone%3AMVC

[Benjamin Delespierre]

Merci donc de prendre le problème dans son ensemble et de ne répondre que si vous avez un avis très conceptuel de la chose, le but n'étant pas d'avoir des opinions personnelles, mais plutôt conceptuelles sur les bonnes pratiques à ce niveau là.

C'est compliqué de répondre complétement objectivement à cette question. Il y a autant de façons d'implémenter un MVC que de programmeurs.

Pour ma part, ce n'est pas de la responsabilité du contrôleur de "paramétrer" les vues mais seulement de préparer les données. Normalement, il faut être capable de refondre totalement les vues sans jamais toucher au contrôleurs. De même qu'il faut être capable de changer la couche de modèle sans changer le métier. C'est le principe d'isolation qui est le plus important ici car c'est lui qui apporte une réelle plus-value au paradigme MVC.

Oui, mais exemple avec la génération csv etc. tu pourrais généraliser cela avec une aide de vue qui automatise cela au lieu de le duppliquer, pourtant c'est bien une classe qui va te le générer donc :
- gain important + réutilisabilité + maintenabilité contre :
- duplication de la fonction dans chaque vue

Je trouve que l’argument avancé qui consiste à dénoncer la multiplication des vues pour chacun des usages est déplacé. Une vue correspond à un besoin au niveau du rendu et/ou du format, c'est donc moins un problème de dupplication que de spécialisation. Tout n'est pas toujours factorisable - la plupart des vues sont en réalité spécifiques - et chercher à tout prix à le faire malgré tout est une mauvaise idée qui nuit à la fois aux performances et à la clarté du code produit. On peut évidement imaginer de spécialiser le code pour chaque usage (par exemple avec un héritage), mais cela reviendrait presque à duppliquer les vues donc cela en vaut-il la peine ?
Parfois, il est plus intéressant de dupliquer comme tu dis si les besoins sont différents. Je ne remets pas en question le principe DRY mais je pense qu'il faut aussi tenir compte du KISS.

Au final, il semblerait qu'on soit arrivé à un consensus au niveau des aides de vue. Une classe, pour quelque rendu que ce soit (HTML, JavaScript, etc) doit passer par des helper.

Il me semble que ce soit une bonne pratique mais surtout un bon compromis entre respect des règles MVC et optimisation / réutilisation du code.

Qu'en pensez vous ?

Je l'ai fait sur un de mes projets. J'ai créé une couche de vue qui fonctionne par génération de XML puis par une traduction vers XHTML, JSON, XML, CSV etc à l'aide de XSLT. C'est sûr c'est très flexible mais aussi terriblement contraignant: pour chaque besoin spécifique dans une vue, il fallait adapter la XSLT ou en créer une nouvelle. Et je ne parle même pas de la complexité du code à produire. De plus, je me suis vite rendu compte que 90% des vues produisaient du HTML, ce qui rends l'ensemble de la couche un peu absurde: on aurait dit qu'on utilisait un bazooka pour tuer une mouche.

Donc je suis revenu vers une approche plus naturelle ou pour chaque besoin d'affichage, une vue supplémentaire est produite (par exemple: list_products.html.php pour du HTML et list_products.json.php pour JSON). Au final c'est plus performant et plus adapté à la RAD. De plus, ça couvre tout à fait mon besoin et c'est finalement la seule chose qui compte: une solution élégante est une solution simple à écrire et à comprendre

[laville]

Pour ma part, ce n'est pas de la responsabilité du contrôleur de "paramétrer" les vues mais seulement de préparer les données. Normalement, il faut être capable de refondre totalement les vues sans jamais toucher aux contrôleurs. De même qu'il faut être capable de changer la couche de modèle sans changer le métier. C'est le principe d'isolation qui est le plus important ici car c'est lui qui apporte une réelle plus-value au paradigme MVC.

Merci Benjamin, pour moi c'est ce concept qui me semble important et où, effectivement, je peux m'écarter puisque je "m'acharne" à vouloir utiliser les fonctionnalités du Zend_Form pour ne citer que lui.

Au final, si l'on veut, dans le ZF1, respecter cet adage, il me semble qu'il serait nécessaire de :

- Ne plus utiliser les décorateurs, car si modification de présentation => modification du Form SAUF si mis en place dans la vue puis rendu (intérêt ? Pas certain)
- Eviter autant que possible finalement les aides d'action manipulant le Header de la vue (réponses Ajax avec définition du format par exemple) car effectués au niveau du contrôleur
- N'utiliser des aides de vues qu'au niveau du rendu de la vue et non lorsque l'on est encore au niveau du controlleur
- Préparer TOUTES les données pour la vue SAUF cas particulier (parfois tout préparer en terme d'utilisation mémoire / performance n'est pas le meilleur, il est parfois nécessaire de récupérer les données en même temps qu'on les formate dans la vue)
- Etc.

Il est vrai qu'avec cette solution il y aura forcément de la duplication, car mon souhait au départ était l'uniformisation des applications (formulaires, Tableaux, etc.) ce qui est possible puisque je le fais dans mes applications.

Mais si on veut réellement implémenter une solution dite MVC, autant à minima bien séparer cette couche même si cette séparation risque dans certains cas ne pas être possible dû :
- à des problèmes de droit (et encore, bien penser on peut construire des objets complets initialisés en fonction des droits, ce qui résout le problème...)
- à des problèmes de performance / utilisation mémoire

Merci s.n.a.f.u pour le lien, je l'ai lu et leur conclusion c'est que leur implémentation MVC est très souple et peut être trop souple comme beaucoup d'autres Framework métier ... la question pourrait être au final : est-ce que l'implémentation MVC est performante et pas trop idéaliste ?

Cela fera l'objet d'un autre débat si certains veulent en discuter, pour ma part j'ai mes réponses qui me semblent cohérentes vis à vis de tout ce qui s'est dit

Merci beaucoup à vous tous pour vos retours enrichissants

[Benjamin Delespierre]

- Ne plus utiliser les décorateurs, car si modification de présentation => modification du Form SAUF si mis en place dans la vue puis rendu (intérêt ? Pas certain)

Je ne suis pas familier des décorateurs de Zend, pourrais tu m'expliquer concrêtement quel est leur rôle (j'ai bien une vague idée mais je préfère éviter de dire n'importe quoi) ?

- Eviter autant que possible finalement les aides d'action manipulant le Header de la vue (réponses Ajax avec définition du format par exemple) car effectués au niveau du contrôleur

S'il s'agit bien du Header HTTP, ce n'est pas faux de laisser ce traitement à la charge du contrôleur car c'est lui qui est responsable de la prise en charge de la requête HTTP, c'est donc à lui de respecter le protocole (erreurs 40*, 50*, redirections etc.) En revanche, il me parait exclu de lui faire paramétrer le <head> de la vue HTML.

- N'utiliser des aides de vues qu'au niveau du rendu de la vue et non lorsque l'on est encore au niveau du controlleur

Tout à fait.

- Préparer TOUTES les données pour la vue SAUF cas particulier (parfois tout préparer en terme d'utilisation mémoire / performance n'est pas le meilleur, il est parfois nécessaire de récupérer les données en même temps qu'on les formate dans la vue)

J'ajouterai qu'il n'est pas impossible que la vue fasse de la manipulation implicite de données bien qu'il faille l'éviter la plupart du temps.
Une vue pourrait être amenée à charger indirectement un modèle en utilisant une méthode d'un objet renvoyée par le contrôleur, ce n'est pas un grand mal selon moi. En revanche, il est totalement exclu que la vue puisse instancier explicitement (new ou autre) une classe de modèle.

E.G.

Code :

1
2
3
4
5
<h1>Produit xxx</h1>
<?=$product->name?> #<?=$product->ref?>
<?php foreach ($product->getImages() as $image) ?>
<img src="<?=$image->href?>" />
<?php endforeach ?>

Dans l'exemple ci dessus, la méthode getImages va implicitement effectuer une récupération d'informations au niveau du modèle. Bien qu'il soit préférable que cela soit fait au niveau du contrôleur, le laisser dans la vue n'est pas complètement aberrant car ça allège grandement le code du contrôleur et apporte beaucoup de cohérence à la vue.

Note: cet usage présente un inconvénient majeur, lors qu'une exception est levée au sein de la vue, le contrôleur ayant déjà fini son travail (la vue est toujours invoquée en fin de chaine) il devient impossible de manipuler la réponse HTTP pour renvoyer, par exemple, une erreur 500.

- à des problèmes de droit (et encore, bien penser on peut construire des objets complets initialisés en fonction des droits, ce qui résout le problème...)

C'est la responsabilité de la couche ACL de déterminer si un utilisateur à les droits suffisants pour effectuer une action. Par action on entends opération, soit une requête donnée, c'est donc au contrôleur de prendre en charge cet aspect. Ce n'est certainement pas de la responsabilité des autres objets (modèle ou métier) de s'occuper de ça (et encore moins dans leur constructeur).

- à des problèmes de performance / utilisation mémoire

Problèmes qui peuvent être résolus en optimisant son code et/ou en mettant en place des caches. Ce n'est certes pas le MVC qui cause des pertes de performances mais l'implémentation. Prends par exemple le Framework Lithium, tu verra la rapidité d'exécution et pourtant le code est bien plus velu que celui de Zend Framework.

la question pourrait être au final : est-ce que l'implémentation MVC est performante et pas trop idéaliste ?

Je me garderai bien de répondre en ce qui concerne le Zend Framework et je laisse d'autres plus qualifiés que moi en débattre. Je considère pour ma part le MVC comme une bonne pratique, alliant simplicité, performances et évolutivité. Simplicité car ce paradigme n'est vraiment pas sorcier, la tâche la plus ardue consiste à comprendre les responsabilité des différents composants de l'application. Performances car le MVC est assez souple pour permettre des flots de traitement rapides, de la mise en cache ou encore de l'optimisation. Évolutivité car la séparation permet naturellement de modifier ou de réutiliser certains composant sans impacter l'ensemble de l'application.

J'ajouterai enfin que le MVC est incomplet: il n'y a pas de couche métier prévue par exemple. Il est avantageux selon moi de le coupler avec une architecture mutlitiers (ou 3tiers) plus classique.

[laville]

Bonjour benjamin,

Je ne suis pas familier des décorateurs de Zend, pourrais tu m'expliquer concrêtement quel est leur rôle (j'ai bien une vague idée mais je préfère éviter de dire n'importe quoi) ?

En gros tu décore dans ton contrôleur (pour ma part mon contrôleur appelle soit des classes métiers (pas des classes de données) soit des éléments Form, et quand on parle décoration c'est bien l'ergonomie / présentation de chaque élément.
=> On fait dans une classe ce qui devrait être effectué dans une vue.

S'il s'agit bien du Header HTTP, ce n'est pas faux de laisser ce traitement à la charge du contrôleur car c'est lui qui est responsable de la prise en charge de la requête HTTP, c'est donc à lui de respecter le protocole (erreurs 40*, 50*, redirections etc.) En revanche, il me parait exclu de lui faire paramétrer le <head> de la vue HTML.

On est d'accord, quand je parlais de Header, c'était bien évidemment le <HEAD>... parfois je n'utilise pas toujours les bons termes ce qui peut être un problème pour me faire comprendre


En ce qui concerne ta fonction appelée dans ta vue, je suis aussi d'accord, c'est bien une classe "métier" (fonctionnelle, d'accès aux onnées, etc.) qui va récupérer les données, c'est un minima, le must étant de le gérer dans le contrôleur

C'est la responsabilité de la couche ACL de déterminer si un utilisateur à les droits suffisants pour effectuer une action. Par action on entends opération, soit une requête donnée, c'est donc au contrôleur de prendre en charge cet aspect. Ce n'est certainement pas de la responsabilité des autres objets (modèle ou métier) de s'occuper de ça (et encore moins dans leur constructeur).

Un exemple serait que tu sais que l'utilisateur n'a pas le droit de supprimer des données dans ton tableau
=> dans ta vue tu vas contrôler une variable pour savoir s'il faut afficher ou non le bouton de suppression

Seconde solution (pour un objet Form), tu gère les éléments autorisés à être affichés, et la vue gère ce qui lui est renvoyé.

Pour ce qui est des droits d'actions, effectivement, c'est le rôle de l'ACL et à ce niveau là c'est fort bien géré

Problèmes qui peuvent être résolus en optimisant son code et/ou en mettant en place des caches. Ce n'est certes pas le MVC qui cause des pertes de performances mais l'implémentation. Prends par exemple le Framework Lithium, tu verra la rapidité d'exécution et pourtant le code est bien plus velu que celui de Zend Framework.

Humm pas forcément d'accord, un exemple : la génération de tableaux de tableaux / d'objets
=> pour 100 000 enregistrements, calcule l'utilisation mémoire Une solution c'est de sérialiser l'élément pour qu'un tableau de chaines de caractères.
Ceci n'est qu'un exemple, mais parfois de vouloir tout initialiser avant, on arrive dans certains cas (récupération de milliers d'enregistrement avec calcul / moyennes etc) de plomber les performances.
Mais effectivement, c'est des cas ciblés, la majeur partie du temps nous n'avons pas de problèmes de performance à ce niveau là.

J'ajouterai enfin que le MVC est incomplet: il n'y a pas de couche métier prévue par exemple. Il est avantageux selon moi de le coupler avec une architecture mutlitiers (ou 3tiers) plus classique.

Alors là..... oui pour ma part j'ai mes contrôleur, mes dbTable et une classe dans la partie Model qui fait l’interaction entre mon Contrôleur et ma/mes classes Db, c'est elle qui possède les règles métier (et non le contrôleur qui pour moi ne doit gérer que le point d'entrée et le point de sortie, mais cela reste mon avis personnel).

Merci en tous cas pour ton partage d'opinion

[Benjamin Delespierre]

Humm pas forcément d'accord, un exemple : la génération de tableaux de tableaux / d'objets
=> pour 100 000 enregistrements, calcule l'utilisation mémoire Une solution c'est de sérialiser l'élément pour qu'un tableau de chaines de caractères.
Ceci n'est qu'un exemple, mais parfois de vouloir tout initialiser avant, on arrive dans certains cas (récupération de milliers d'enregistrement avec calcul / moyennes etc) de plomber les performances.
Mais effectivement, c'est des cas ciblés, la majeur partie du temps nous n'avons pas de problèmes de performance à ce niveau là.

J'ai résolu le problème en utilisant un décorateur de PDOStatement qui se comporte comme un itérateur. L'idée est d'avoir une seule instance qui sert de curseur et qu'on déplace sur la collection (qui fera les fetch on-demand).
L'avantage à disposer d'un itérateur c'est que non seulement un peut se "promener" dans le jeu de résultats mais surtout qu'on peut le décorer à nouveau avec des filtres, des limiteurs etc.

Voici concrêtement à quoi ça ressemble:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$query = "SELECT * FROM table;";
$stmt = $pdo->prepare($query);
 
if (!$stmt->execute())
  throw new RuntimeException("Query error duh...");
 
$model = new MyModelClass();
$stmt->setFetchMode(PDO::FETCH_INTO, $model);
 
$it = new PDOStatementIterator($stmt);
$itit = new LimitIterator($it, 10, 20); // prendre les items entre 10 et 30
 
foreach ($itit as $m) {
  $m->method();
  echo $m->data;
}

[laville]

Oui, mais tu es d'accord avec moi, tu vas initialiser un Objet au niveau du contrôleur, le passer à ta vue, et cet objet va gérer le rendu

=> C'est cela que me reprochent mes collègues car ils considèrent que cet objet fait tout

Pour eux c'est un autre objet qui doit gérer dans tous les cas le rendu... mais parfois je trouve cela plus simple d'utiliser la fonction __toString() d'un objet même s'il a été instancie à partir du Contrôleur, et même s'il gère à la fois la récupération des données et son rendu.
Mais encore une fois c'est peut être moi qui extrapole puisque ma super classe gère aussi :
- le rendu du Tableau (JqGrid en PHP)
- le rendu du formulaire associé (on lui donne une classe DbTable, il génère le reste => gain de temps pour des tables d'administration monstrueux )
- la récupération des données et le formatage XML / CSV / JSON

Bref un vrai monstre, et à mon avis c'est surtout cela qu'ils reprochent à cette classe

Mais là on relance le débat (qui ne sera jamais clos ^^)

[Benjamin Delespierre]

Oui, mais tu es d'accord avec moi, tu vas initialiser un Objet au niveau du contrôleur, le passer à ta vue, et cet objet va gérer le rendu

Pas du tout, ce n'est pas la collection qui génère le rendu chez moi.

Mais encore une fois c'est peut être moi qui extrapole puisque ma super classe gère aussi :
- le rendu du Tableau (JqGrid en PHP)
- le rendu du formulaire associé (on lui donne une classe DbTable, il génère le reste => gain de temps pour des tables d'administration monstrueux )
- la récupération des données et le formatage XML / CSV / JSON

Selon moi cette classe à tout simplement trop de responsabilités. Faire un wrapper capable de décorer un modèle ou une collection pour l'affichage: d'accord. Faire une classe capable de tout faire elle même: non !

Bref un vrai monstre, et à mon avis c'est surtout cela qu'ils reprochent à cette classe

Et là dessus je me range à leur cotés

[laville]

Selon moi cette classe à tout simplement trop de responsabilités. Faire un wrapper capable de décorer un modèle ou une collection pour l'affichage: d'accord. Faire une classe capable de tout faire elle même: non !

Citation:
Bref un vrai monstre, et à mon avis c'est surtout cela qu'ils reprochent à cette classe
Et là dessus je me range à leur cotés

Sur ce point tout le monde était d'accord, c'est disons une super classe, mais TROP, elle doit être découpée (à mort la monarchie longue vie au MVC XD).

Pas du tout, ce n'est pas la collection qui génère le rendu chez moi.

D'accord, ton exemple était simplement pour synthétiser, le

Code :

echo $m->data;

était là simplement pour dire que tu vas afficher le rendu de l'objet (le data pourrait être une valeur), j'avais mal compris