Hello à tous,

Je fait de plus en plus de MVC (bien ) , mais sur certain point je demande encore à être convaincu.

Etude de cas sur l'affichage d'une liste de client avec adresse, tel, nom, prénom 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 au fur et aà mesure ? (ca devient lourd)

3/ ou bien j'ai rien compris au MVC


Merci

3, je dirais. Le MVC se justifie dans des applications lourdes, ou qu'on veut très évolutives, ou on veut une abstraction entre les données, la logique et la présentation.

Dans ton cas, afficher une liste de clients, quelques lignes PHP suffisent. A moins de vouloir intégrer ça dans une structure plus abstraite, générale qui existe déjà, je ne vois vraiment pas l'intérêt d'essayer d'attraper une mouche avec un GAU-8.

C'est parce que tu t'appelles pas Scwartzeneger, sinon tu verrais tout de suite l'intérêt d'une telle arme pour, non seulement attraper ta mouche, mais également au passage, tuer une 50aine de terroristes, arrêter 15 missiles sol-sol avant qu'ils ne détruisent l'empire state building et sauver le monde d'une attaque extraterrestre !

Plus sérieusement, le principe du MVC est surtout de séparer des métiers "en théorie" très différents : dba, graphiste et développeur (en théorie, parce que dans la majorité des structures, les développeurs ont souvent tendance à jouer les 3 rôles au sein d'un projet).

L'intérêt est pour chacun de se préoccuper de la partie qui le concerne sans se soucier de ce que font les autres : le "graphiste" n'a pas besoin de savoir quelle données sont lues ni comment elles sont transformer pour savoir comment les mettre en page. Le développeur métier se moque de savoir comment sont stockés ou affichés ses calculs. Le dba se contente de gérer ses données sans se préoccuper de savoir d'où elles viennent ni où elles vont

C'est donc surtout l'aspect de travail collaboratif qui est facilité avec ce framework (et qui est à mon sens plus facile à mettre en place avec du C ou du Java qu'avec du php qui laisse trop de liberté à chacun). Cette architecture modulaire a également l'avantage de pouvoir évoluer facilement puiqu'il suffit d'ajouter des contrôleurs pour étendre les fonctionnalités, des vues pour proposer différentes formats de mise en page, etc. On peut donc donner à deux modules à réaliser à deux équipes, tout en sachant qu'ils pourront facilement s'intégrer ensemble.

Je rejoint donc Berzemus dans le fait qu'il faut aussi savoir qualibrer un projet pour choisir l'architecture la mieux adaptée à sa structure, et pas se retrouver avec une usine à gaz en choisissant un framework juste parce qu'il est "à la mode" . Ce modèle n'est clairement pas destiné à l'utilisateur (en therme de perf ou autre) mais bien aux développeurs (et donc à la société) pour faciliter leur travail et améliorer les coûts de production sur de gros projets. Sur de petits projets, ils passeront plus de temps à mettre en place le framework qu'il n'en faudrait pour faire script qui liste tes 1000 enregistrements

Résultat de tout ça, t'es pas plus convaincu, mais au moins maintenant, tu sais pourquoi

Ryle,
Je sus exactement d'accord avec toi, c'est précisemenct ce que je pense, et s'il n'y a pas de droit d'auteur sur ton post , je pense que je vais le lire à haute voie demain pendant la réunion des développeurs web que j'anime

Merci