Hello à tous,
 
  Je fait de plus en plus de MVC (bien) , mais sur certain point je demande encore à etre convaincu.
 
  Etude de cas sur l'affichage d'une liste de client avec adresse, tel, nom, prenom sur 1000 lignes ?
 
  Comment on fait en MVC ?  
 1/ l'idée la plus simple est de chargé dans le modèle un tableau php contenant toutes les infos, puis dans la vue de faire un foreach du tableau
 
  Mais d'un point de vue performance c'est affreux ca !!! faut attendre que le tableau php soit remplit avant de renvoyer le 1er octet au client
 
  2/ ou bien faut t'il que le controleur appel le modele par tanche de 100 clients puis envoie ca à la vue ? (ca devient lourd)
 
  3/ ou bien j'ai rien compris au MVC :-)
 
 
Merci
 

Salut,
 
En fait tu te dis que le traitement irait plus vite en bouclant sur le recordset directement, plutot que de le boucler entièrement pour le mettre dans un tableau et de donner ce tableau à la vue et d'ensuite boucler sur le tableau.
 
Ai-je compris ta question ?

 
oui ca me semble evident (bien que ce ne soit que ma logique et non pas un test qui me fasse arriver à ce raisonnement)
 
Cela revient à charger un enorme tableau en RAM (1000 lignes * n colonnes) pour ensuite le relire.
 
et donc la question est comment eviter cela tout en faisant du MVC ?

Ben la solution serait de rapprocher le HTML (Vue) de ton recordset pour qu'elle puisse le fetcher au lieu de boucler un array.
 
Ca impliquerait que ta vue ai des notions de consultations de recordset, ce qui est je pense une notion trop complexe pour une vue.
 
A mon sens une vue doit se limiter a faire des IF, FOREACH, mais rien de plus compliqué.
 
A priori je dirai donc que ce n'est pas compatible avec un vrai MVC :s

En même temps, je vois pas l'intérêt d'afficher 1000 lignes d'un coup dans une IHM! C'est complètement anti-ergonomique...Dans ce cas là, on fait un tableau paginé (avec entre 20 à 50 enregistrements), triable, et si possible avec 2-3 critères de recherche pour filtrer. Et là, miracle, les perfs redeviennent bonnes...

http://fr3.php.net/manual/en/class.traversable.php
 
Mais je suis d'accord avec Rufo, il est assez rare qu'afficher 1k records soit une bonne idée.

intéressant le tranversable, ca devient un peu technique, mais intéressant.
 
La raison d'un grand tableau (dans ce cas 1000 lignes par 4 colonnes, d'autre fois 100 lignes par 40 colonnes), est que les sites que ma société développe, réalisent des tableaux de bord à partir de grande quantité de données (utilisé en intranet par nos clients). Donc pas vraiment du web traditionnel et c'est peut etre pour cela que MVC n'est peut etre pas tout à fait adapté.

Genre indicateurs statistiques, toussa ?
 
A vue de nez, plus que le MVC, c'est le transactionnel que je remettrais en cause.
Une petite procédure "batch", et un enregistrement du fichier généré -tant qu'à faire en PDF (je suppose que c'est destiné à l'impression)...

Là où je bonne, on fait aussi des tableaux de bords, le résultat n'est pas un tableau de 1000 lignes; c'est absolument pas lisible. Un tableau de bord, c'est une vue synthétique. Par contre, les calculs menant à cette synthèse peuvent tout à fait porter sur plusieurs milliers d'enregistrements. mais dans ce cas là, on fait tourner un script la nuit pour consolider les données (via un ETL, par ex). Y'a aussi de bons outils pour ça, en GPL, Pentaho, par ex.

parfois possible et pré-calculer et stocker un pdf, parfois impossible (cas ou c'est l'utilisateur qui choisi les colonnes qu'il souhaite voir dans son rapport)
 
Et parfois l'utilisateur souhaite voir l'html (car plus visuel, plus naturel, intégration dans le reste du site) et si ca lui plait il veut le pdf (pour sauvegarde et/ou impression) --> c'est ce cas là qui ma fait aimer le MVC un modèle pour 2 vues.

 
ca commence à faire de l'hors sujet, merci de ne pas débattre sur le pourquoi des besoins des mes clients.
 
La question etait comment gérér des calcul lourd + affichage lourd avec une technique MVC , tout en restant transactionnel et en php (est possible ? est ce adapté )

Je pense que c'est arrivé à pas mal d'entre nous de rencontrer des clients qui avaient exprimés un besoin déjà orienté techniquement alors qu'en creusant, on découvre que leur réel besoin est tout autre et que la solution qu'ils proposent n'est pas adaptée. En tant que développeur, c'est aussi notre rôle de conseiller, et dire à un client quand ce qu'il demande n'est pas judicieux et de lui proposer qq chose qui réponde mieux à son besoin.
Maintenant, pour ton besoin, oui, en php c'est faisable (vu le temps de traitement, lancer le script la nuit serait mieux) mais ce n'est pas le plus adapté. Si le besoin initial est de faire un tableau de bord, un outil comme Pentaho est plus adapté. C'est GPL, y'a une interface web et ça permet de faire de beau rapports.

Hors sujet.
 

 
On à déjà regardé si des techno, langage, logiciel pouvait nous prémacher le travail, mais les rapports sont tellement différent d'un projet à l'autre, que l'ont doit rester sur un langage aussi souple que le php. (pour un client, on ne maitrise même pas le contenu du SELECT et du WHERE de la requete SQL, c'est lui qui saisi directement dans des textarea et hop le rapport doit s'afficher :-) )
Pentaho est qd meme impressionnant, mais ne convient pas à nos besoins.
 
Merci quand même pour tes avis et infos.

MVC a été créé pour sur des interfaces d'apps "lourdes" (bureau) en Smalltalk 10 ans avant que le web ne devienne une idée dans le cerveau de Tim Berners Lee...

 
    Ok donc on peut passer à 10 000 lignes  

Si c'est pour du web et non du local, il vaut mieux que la page soit compressée [ob_start(); + blabla + ob_end_flush();] avant d'etre envoyée.  
En envoyant tout de suite la sauce (enregistrement par enregistrement), tu perds le bénéfice d'une compression... et c'est dommage !

+1, et plus précisement avec Iterator et Countable, on peut wrapper un mysql_result par exemple, ou ce qu'on veut.

bon ben si meme florentG confirme cette solution je vais franchement me pencher dessus.
Mais une question arrive d'elle meme faut t'il toujours utiliser une classe traversable, ou bien est ce fonction de la quantité des données à passer entre le modele et la vue ?