Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Salut,
je ne viens pas ici pour troller mais je m'interroge sur l'interet de passer au MVC.
Je pense avoir bien compris le principe théorique : séparation données, présentation, etc.... mais bon ca on pouvait le faire avant.
J'ai donc commencé à m'y mettre mais je trouve cela d'une telle complexité à mettre en ouvre que j'ai vite abandonné. surtout lorsque les pages se compliquent
Pourrait on donc me dire les pour et les contre d'implémenter une telle solution, hormis la raison qui fait que ce soit à la mode?
En gros, convainquez moi
merci
Hors ligne
Bonjour,
La première chose : pour un projet hyper simple, tu peux t'en passer.
Un MVC de façon générale n'est pas lié au Zend Framework et tu peux tout à fait en faire un à ta sauce. Ca dit juste :
- le modèle contient les données à manipuler (sous forme d'objets),
- le controlleur traite les données d'entrée (GET, POST,...) et fait les traitements nécessaires et choisit la vue à afficher.
- la vue c'est le code HTML à renvoyer à l'internaute
Quand un projet devient complexe, le MVC a plusieurs intérêts :
- si vous êtes plusieurs à coder, le graphiste peut faire son HTML sans rien comprendre à PHP
- ça diminue la complexité globale du code (si, si je t'assure...). En effet si tu dois coder un forum, tu commences par coder les classes qui permettent de manipuler les données dans la base (le modèle). Parallèlement tu crées le design et les formulaires en HTML (la vue). Et enfin tu crées les controlleurs qui récupèrent les données des formulaires et qui choisissent la vue en fonction des résultats. Ca fait beaucoup de fichiers à coder mais chaque fichier est assez simple à faire. Alors que le même traitement en un seul fichier devient un enfer insondable.
- ça facilite le débug : quand tu as un problème, tu sais en général si ça vient du modèle, du controlleur ou de la vue, comme chaque fonction est plus simple, c'est plus facile à corriger
- ça limite les régressions pendant le débug : quand il y a un bug dans le modèle, ça n'a en général d'impact que sur le modèle, tu n'as pas l'ensemble de ton code à corriger
Cela dit, utiliser un MVC apporte au départ une couche de complexité réelle et quand le problème vient effectivement du MVC lui même, ça peut être des bugs assez compliqués à gérer...
Perso je ne travaille que sur des sites relativement complexes et qui évoluent pas mal (mes clients me demandent des modifications fonctionnelles ou des évolutions dans la présentation,...). Dans mon cas le MVC me fait gagner beaucoup de temps. C'est bien plus qu'une mode
A+, Philippe
Hors ligne
Euh....
(oui je sais c'est une profonde reflexion).
Pour moi tout l'interêt du MVC est cette séparation. Après il y'a différente manières de mettre ça en place.
Que trouve tu de compliquer déjà ?
Hors ligne
Idem philippe
C'est sur qu'il y a un effort a faire au début si on est pas habitué à utiliser ce pattern. Mais sur des gros projets et quand on est plusieurs a dev, cela apporte un réelle gain de temps et de la rigueur. Idem pour la maintenance.
Hors ligne
ca se tient
mais imaginons que je sois seul sur un projet, sur quel critères dois je me baser pour déterminer si c'est la solution à utiliser? comment savoir si le projet est suffisamment complexe ou trop simple? voire même, qd peut on dire qu'un projet est simple ou devient complexe?
Hors ligne
J'aurais tendance à dire que dès que tu as plus de 2 ou 3 formulaires à traiter dans un site tu y gagnes déjà... sinon une fois que tu as mis en place la structure MVC, tu peux la réutiliser pour tous tes sites, comme ça s'ils évoluent vers plus compliqué après, tu n'as pas à tout refaire...
Philippe
Hors ligne
J'ai cet après midi improvisé une démo sur les avantages d'un système.
Copie de l'ensemble du framework et quelques lib perso 1mn
création d'un fichier de conf pour la démo 10s
création d'une table dans la base 1mn
création d'une classe Model.php avec accès au donné par dérivation d'une classe existante 30s
Création d'un CRUD par dérivation d'un controlleur de crud générique 1mn
copie des modèles d'écrant pour le crud (3 page html sans php) 10s
ajouter quelques champs dans les modèle 10s
lancement de l'application avec affichage de la liste des éléments dans la table ajout suppression et toute la navigation
total 3mn
bon ok pour arriver à une telle démo il faut avoir gratter du framework en tout genre et améliorer celui de zend par quelques ajout mais franchement pour rendre son code réutilisable et en profiter y a pas mieux.
maintenant un framwork est un cadre de travail pour une approche d'un certain type de pb et utiliser un framework hors de son domaine d'application n'est pas ce qu'il y a de mieux. donc il faut surtout avant de se lancer voir l'adéquation du pb avec le framework envisagé.
A+JYT
Hors ligne
sekaijin a écrit:
Création d'un CRUD par dérivation d'un controlleur de crud générique 1mn
heu c quoi un crud?
sekaijin a écrit:
maintenant un framwork est un cadre de travail pour une approche d'un certain type de pb et utiliser un framework hors de son domaine d'application n'est pas ce qu'il y a de mieux. donc il faut surtout avant de se lancer voir l'adéquation du pb avec le framework envisagé.
encore faut il connaitre suffisamment le framework, non? je crois que je n'ai plus qu'a le pratiquer un peu alors
mais sans réel projet, difficile de s'accorder du temps et de se motiver
Hors ligne
CRUD Create Retrive, Update Delete
un crud est un ensemble d'action permettant à l'utilisateur de faire tout cela sur une ressource donnée.
A+JYT
Hors ligne
Hors ligne