Discussion :

[ChriGoLioNaDor]

Bonjour,

J'utilise php5 depuis quelques mois, et cela fait un moment que je me documente sur le modèle MVC. Mon soucis est que, bien que je pense que ce modèle permette de pouvoir avoir des modules fixes (mes classes modèles) réutilisables, et des modules customisable (les classes vues), j'ai l'impression que le MVC reste pour les sites un doux rêve. Je m'explique :

Je prendrais l'exemple d'un livre d'or.

- 1e défaut trouvé : même en séparant le modèle de la vue, un client peut vouloir ajouter des fonctionnalités à son livre d'or.
Ex : l'un veut afficher l'heure, le 2e veut gérer les émoticons, le 3e un système antispam, etc.
Dans ce cas, on peut créer un module "super complet" qui gère toutes les fonctionnalités, mais dans ces cas là on aura à terme une usine à gaz capable de tout faire, mais lentement (36 conditions pour voir quelle fonctionnalité est activée), et pas forcément de façon fiable, s'il y a trop de cas à prévoir.
Sinon, on est obligé de "customiser" ses classes modèles, et là on perd une grande partie de l'intérêt du mvc : avoir des modules réutilisables quel que soit le cas.

- 2e défaut trouvé : Utiliser un modèle MVC implique de diviser chaque module en 2 classes : l'une pour le modèle (commune), et l'autre pour la vue (différente pour chaque site). On se retrouve donc avec 2 fois plus d'objets à gérer, qu'il faut biensûr faire communiquer ensemble.

- 3e défaut trouvé : Ce modèle implique aussi l'ajout d'objets supplémentaires : si je veux que mon header aille chercher des infos (métas, title, keywords) dans une BDD, il va me falloir là encore 2 classes. Idem pour le footer, s'il doit afficher des données dynamiques (par exemple le temps d'exécution d'un script, ou le nombre de visites).


Je passe les autres défauts qui pourraient exister, pour en venir à ma question.

- Est-il vraiment utile, concrètement, de séparer modèle et vue, dans un site, en sachant qu'avec le CSS, il on peux déjà personnaliser l'affichage grandement, sans avoir à diviser en 2 toutes les classes?

- En termes de réutilisation, le modèle objet permet déjà de créer des modules réutilisables (ce qui n'était pas forcément le cas de PHP4), avec des variables de classe etc. Le modèle MVC ne complique-t'il pas la chose inutilement? Il suffit de coder "convenablement" l'affichage, utilisant des balises appropriées, et de modifier le design par CSS. A la limite, on peux consevoir une fonction "affichage" dans sa classe, qui ne s'occuperait que de cela.

- L'utilisation des exceptions avec un modèle MVC est pour moi une énigme. En effet, une vue ne pouvant pas appeler de modèle, vu que le modèle est le plus propice à générer des exceptions (forcément, c'est lui qui fait le traitement), les exceptions seront forcément récupérées par le contrôleur. Or, ce n'est pas son rôle d'afficher une erreur (affichage->vue)!

Bref au final, j'ai un peu l'impression que le modèle MVC est comme son nom l'indique... un modèle, mais théorique, et pas forcément applicable. Cependant, je préfère vous demander votre avis, à vous qui avez peut être une autre vision de la chose, qui utilisez ce modèle, et qui avez peut être compris des choses que je n'ai pas compris.

Que pensez-vous de mon analyse? Suis-je dans le vrai?

[Taum]

Salut,

Tout d'abord je voudrais signaler que je n'ai que vaguement essayé d'appliquer le modèle MVC en PHP5 (quand je me suis initié au zend framework). En revanche j'ai commencé récemment ruby on rails, un framework qui est conçu pour exploiter largement le modèle MVC.

Maintenant pour répondre à tes interrogations :
1) Déjà je pense que le fait de penser que seul la vue change entre plusieurs sites est une erreur : ton premier exemple le montre bien. Si plusieurs sites ont besoin de fonction différentes, les controlleurs seront forcément différents (même si une partie des fonctionnalités sera surement commune). Si les données à manipuler sont différentes (par ex. la date dans un cas alors qu'on s'en fiche dans un autre cas) les modèles seront aussi différents.
Cela dit ce n'est pas parce que quelques fonctionnalitées changent que tout est à refaire à chaque fois.
Ou alors tu devras faire comme tu dis un "super module", dont l'inconvénient est forcément qu'il contiendra du code inutile pour ceux qui ne l'utiliserons pas a 100%.

2) Je vois pas trop ce que tu veux dire par là
Evidement si tu codes tout depuis le départ, c'est plus de travail. Cependant les relations controlleurs <-> vues devraient être gérées par le framework : ton controlleurs définies quelles variables sont disponibles, ta vues les utilises. Si tu as besoin de passer du temps pour mettre en place cette relation, il y a effectivement un problème quelque part


3) Alors là je suis completement perdu
Encore une fois c'est le rôle du controlleur de récuperer toutes les données de ta page et à la vue des les utiliser, je vois pas à quoi servent des classes header, footer ... ?


D'une manière globale, j'ai l'impression que tu essayes de concevoir un site avec l'architecture MVC en partant de rien. Si tu n'as pas de framework qui implémente cette architecture, effectivement c'est beaucoup d'énergie dépensée pour pas grand chose



Pour ce qui est des exceptions, voilà une manière de les gérer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
class TrucController {
function actionMachin() {
  try {
    // Code du controlleur qui peut lever des exceptions
 
    $view->render(); // On appelle le template de base
  }
  catch (ErreurMachin $e) {
    $view->renderError($e->message); // On fait appelle un template spécial pour les erreurs
    // on pourrait aussi rediriger sur une autre page, etc...
  }
}
}

Certaines erreurs peuvent même être attrappées au niveau de l'application, pour être traitée de la même manière quelque soit le controlleur qui les génere.

Par exemple dans une appli Rails, mon modèle peut lever une erreur RecordNotFound si on lui demande de récuperer un objet qui n'existe pas. L'application attrape ces erreurs et affiche une page 404. En revanche, n'importe quel controlleur peut attraper cette erreur avant l'application (par exemple pour rediriger vers la liste des articles à la place). Je trouve ça a la fois simple et extremment puissant

[ChriGoLioNaDor]

D'une manière globale, j'ai l'impression que tu essayes de concevoir un site avec l'architecture MVC en partant de rien. Si tu n'as pas de framework qui implémente cette architecture, effectivement c'est beaucoup d'énergie dépensée pour pas grand chose

En effet, je n'utilise pas de framework, ce qui explique probablement ton incompréhension par rapport à mes questions. Je n'utilise pas de framework car je n'en éprouve pas vraiment le besoin : je les trouve beaucoup trop lourds (et puissants) pour ce que je veux faire, qui se veut justement le plus simple possible. De plus, qui dit framework dit formation, utilisation d'un composant que je ne maitriserais pas à 100% (forcément, je ne vais pas m'amuser à le décortiquer), et donc risque de problèmes au final

3) Alors là je suis completement perdu
Encore une fois c'est le rôle du controlleur de récuperer toutes les données de ta page et à la vue des les utiliser, je vois pas à quoi servent des classes header, footer ... ?

La raison est simple : dans mon header, je remplis les champs title, description et keywords. Or, ces données se trouvent dans une table de ma BDD, afin de pouvoir facilement les modifier via une interface utilisateur, par exemple. Or, ce n'est pas à ma vue ni à mon controleur de rechercher les données (d'après la description du modèle MVC) dans la BDD. Il me faut donc passer par un modèle (qui est représenté par ma classe "header"), qui ira faire la requête et retourner les données. Suite à quoi une vue (2e objet) "affichera" le résultat.


Si l'intérêt du MVC n'est pas d'avoir des modules réutilisables, quel est son intérêt? En effet, si je dois à chaque fois modifier ma vue, mon controleur, et mon modèle, j'ai du mal à voir pourquoi tout séparer. On ne peux pas dire que c'est pour séparer les taches, puisque tout est lié. Si je touche à mon modèle, je devrais très probablement modifier ma vue. Donc l'un et l'autre est lié.

Bref, j'ai vraiment du mal avec ce modèle! Mais merci d'essayer de m'éclairer Taum

[Taum]

La raison est simple : dans mon header, je remplis les champs title, description et keywords. Or, ces données se trouvent dans une table de ma BDD, afin de pouvoir facilement les modifier via une interface utilisateur, par exemple.

Dans ce cas précis, je verais plutôt ça comme de la configuration que réellement comme un modèle (un modèle étant lié au métier). J'aurais donc plutôt tendance à faire en sorte que la vue aille directement chercher les informations nécessaires à se configuration.
Mais encore une fois je n'ai pas une grande expérience du MVC donc peut-être qu'il existe des moyens de gérer ce type de cas en particulier ...



Quant aux frameworks voilà comment je vois les choses : je préferes passer 1h à chercher comment faire ce que je veux avec mon framework, que 2h à coder la fonctionnalité en question (voire plus car j'ai souvent tendance à vouloir faire trop d'abstraction).
Cependant je t'avoues qu'effectivement les quelques frameworks PHP que j'ai pu testé ne m'ont pas vraiment convaincu, et c'est en regardant d'abord vers Python (avec Django) puis vers Ruby (avec Rails) que j'ai réalisé l'interêt d'un bon framework. (je dois préciser que je n'ai jamais touché à Java (structs & co.))
Naturellement je n'utilise qu'une petite partie des possibilités offertes par le framework, mais je pense que c'est interessant ne serait-ce que pour la structure qu'impose l'utilisation d'un framework.

[ChriGoLioNaDor]

Tu vois, c'est justement pour des choses comme ça que j'ai du mal avec le MVC Ca me semble beaucoup trop abstrait pour être vraiment utilisable comme tel.

Par exemple, si j'affirme que ma vue est représentée par mon fichier CSS, tu ne peux pas vraiment me contredire : une vue n'est qu'un nom représentant une "couche" qui gère la mise en forme du contenu retourné par le modèle. Or, mettre en forme, c'est bien le boulot du CSS. Le HTML gère à structurer tes données, pas à les mettre en forme (du moins théoriquement). La preuve est que la présentation d'une même page varie d'un navigateur à l'autre. On a donc une structure fixe, et le navigateur qui se dit "tiens, là j'ai un titre, je vais le mettre en telle taille, en gras etc".

Idem pour la couche métier : certains préconisent de rajouter une classe d'abstraction de SGBD. Ca peut être utile en effet, mais en aucun cas cela ne fait partie du modèle MVC.

Enfin, le contrôleur. Il est sensé coordonner le tout. Mais d'un autre coté, je peux te dire que mon contrôleur, c'est mon serveur Apache, avec une redirection d'url qui redirige mon URL pour charger le fichier voulu. Ce dernier sera lui aussi considéré comme contrôleur, puisqu'il appellera ma classe (forcément, je suis bien obligé d'avoir un fichier pour appeler une classe objet :p)...

Bref au final, on a des notions très abstraites, qui bien qu'étant justes dans la théorie, peuvent se traduire de mille façons différentes, et à différents degrès de rapprochement par rapport à ce modèle. Ce qui est assez dommage, car pour moi, un modèle est justement quelque chose de concrêt, qui donne un exemple précis qu'il est conseillé de suivre. Quelque chose qui n'est que très peu soumis à interprétation.

[zyongh]

Personnellement, j'ai pris des semaines pour comprendre comment fonctionne le MVC et comment l'utiliser. Il est évident que le MVC ne sert à rien pour des petits modules. Par contre pour les gros projets... Je ne vois pas comment faire sans.

J'ai surtout l'impression que tu confonds le rôle de chaque élément et principalement Controller et Models. Ce n'est pas le controller qui est chargé de récupérer les variables mais le model.
Par exemple, tu fais un site de 100 pages ou plus en mélangeant dans le code Models et Vues. Puis tu veux ajouter une fonctionnalité qui devra être récupérer par une trentaine de pages. Tu dois modifier la trentaine de pages. Bonjour la galère!!! Maintenant le même site en MVC. Tu as juste à ajouter un model différent et il est pris en compte par les vues. Le Controller ne fait rien d'autre que mettre en relation la Vue sélectionnée et le Model qui a récupéré les données nécessaires (dans une BDD par exemple). Encore mieux, les modèles de conceptions ne se limitant pas aux MVC, tu peux sur cette option créer un décorateur. Et l'utilisateur ne sait jamais s'il utilise le véritable objet ou son décorateur.

Donc petit projet: MVC inutile
Gros projet: bien réfléchir avant de faire n'importe quoi.

[ChriGoLioNaDor]

J'ai surtout l'impression que tu confonds le rôle de chaque élément et principalement Controler et Models. Ce n'est pas le controller qui est chargé de récupérer les variables mais le model.

Non non, j'ai bien compris les différences : vues -> affichage, modèle -> traitement + recherche des données, et controleur-> synchro du tout (appel des différents modèles / vues)

Par exemple, tu fais un site de 100 pages ou plus en mélangeant dans le code Models et Vues. Puis tu veux ajouter une fonctionnalité qui devra être récupérer par une trentaine de pages. Tu dois modifier la trentaine de pages. Bonjour la galère!!! Maintenant le même site en MVC. Tu as juste à ajouter un model différent et il est pris en compte par les vues. Le Controller ne fait rien d'autre que mettre en relation la Vue sélectionnée et le Model qui a récupéré les données nécessaires (dans une BDD par exemple).

Là justement, je ne suis pas tout à fait d'accord. Dans ton cas, tu me dis qu'il n'y a qu'à ajouter un modèle différent. Mais si tu ajoute ce modèle, il va bien falloir modifier le controleur afin qu'il l'utilise, ton modèle. Il ne peut pas savoir qu'il doit utiliser ce nouveau modèle mais pas l'ancien Donc au final, tu vas devoir modifier le controleur de chaque page, et ce pour les 30 pages! De même, si tu ajoutes une fonctionnalité, il y a fort à parier qu'il va faloir modifier la vue, pour qu'elle affiche les nouveaux éléments intégrés... Donc au final, tu vas bien devoir modifier les 3 éléments


Je dois justement refaire un site de plus de 200 pages distrinctes! (site de e-commerce plutot complet!), et justement, je veux me renseigner au mieux avant sa refonte, pour voir ce qui sera le plus facile à entretenir, et pour le moment, un truc bien ficelé genre CSS pour la présentation, URL-rewriting pour le référencement, contrôleur principal (index.php) qui gère l'inclusion du bon fichier et vérifie les droits pour les admin (mais logiquement cela ne devrait pas se faire ici, avec le modèle MVC :p ), et un contrôleur secondaire par action qui gère l'appel des fonctions de mes objets, ça me semble le plus simple.

En fait j'intègre déjà la notion de controleur, avec mon mode de développement actuel, puisque j'ai bien un controleur principal, et chaque objet a 1 ou plusieurs fichiers (1 par fonction principale) ne servant qu'à créer l'objet, et appeler ses fonctions. Et là dessus, j'en suis très contant. Mon soucis est sur la séparation de la présentation et du traitement. Pour le moment, mes fonctions traitent les action puis affichent via des echo ce qu'il y a à afficher, balisé succintement (souvent un div, ou un tableau pour les données tabulaires). Après, mon CSS s'occupe de la mise en page.

J'ai du mal à voir ce que m'apportera la séparation vue/modèle, même si je comprends bien ce que chaqu'un des deux a comme but.

[Dia_FR]

séparer la vue et le modèle :
- tes données sont dans une BD mysql, tu es dans l'obligation de passer à un stockage sous fichiers XML => ta couche modèle va changer, ta vue n'en saura rien
- tu es pressé par le temps sur ton projet, tu embauches un designer, tu te mets d'accord avec lui sur l'interface vue/contrôleur, vous vous séparez le travail de manière extrêmement simple
- tu es rappelé dans 6 mois pour faire des modifs sur ton site, tu sais de suite quelle couche du modèle MVC est concernée par les modifs

dans le cadre un projet dans ma licence, on a du faire une ébauche de site e-commerce avec symfony
en cumulé, et sans connaître à la base ni le framework ni le fonctionnement du modèle MVC, en 5 jours j'avais un truc basique mais potable
et surtout, je savais exactement comment est structurée l'appli

peut-être que nos posts ne te font pas vraiment voir l'intérêt d'un framework (cakephp ou symfony pour ma part) et du MVC mais lance toi avec ça pour refaire ton site commercial et je pense que passée la prise en main, tu rendras vite compte par toi-même des gains

PS : le framework te donne les outils nécessaires pour gérer les droits et de manière générale, apporte un gain important de productivité

[zyongh]

Là justement, je ne suis pas tout à fait d'accord. Dans ton cas, tu me dis qu'il n'y a qu'à ajouter un modèle différent. Mais si tu ajoute ce modèle, il va bien falloir modifier le controleur afin qu'il l'utilise, ton modèle. Il ne peut pas savoir qu'il doit utiliser ce nouveau modèle mais pas l'ancien Donc au final, tu vas devoir modifier le controleur de chaque page, et ce pour les 30 pages! De même, si tu ajoutes une fonctionnalité, il y a fort à parier qu'il va faloir modifier la vue, pour qu'elle affiche les nouveaux éléments intégrés... Donc au final, tu vas bien devoir modifier les 3 éléments

C'est là que tu n'as pas compris l'utilité du Controller. Tu code le controller pour qu'il analyse la requete (ce qui a été saisi dans la barre d'adresse du navigateur) et selon les valeurs dans la requete il redirige vers la page (le model) qui effectue l'action. Donc tu modifies l'objet (soit dans l'objet lui-même soit grâce à un Decorator) Et ton Controller ou ta Vue ne change pas excepté si tu dois afficher une info complémentaire dans ta Vue (une autre variable récupérée par le model par exemple.

Exemple: la personne saisit un formulaire et ensuite tu affiches les données saisies pour vérifications sur la page suivante (ciblée avec l'attribut action dans la balise form). Ton URL peut donc être:
URL/valider_formulaire.php?do_action=verifie_saisie&affiche=resultat
Le Controller va décortiquer l'URL et va récupérer verifie_saisie et resultat et va appeler d'abord la page verifie_saisie.php (qui peut contenir une Classe par exemple: class ClassVerifieSaisie implements InterfVerifieSaisie { /* code */ } ) puis si toutes les données sont validées afficher la page resultat.php qui va insérer les données dans la base. Donc tu peux très bien ajouter une option dans le model et tu n'as pas à modifier les 30 Vues différentes qui appellent ce modèle.

J'ai du mal à voir ce que m'apportera la séparation vue/modèle, même si je comprends bien ce que chaqu'un des deux a comme but.

Etudie encore un peu. J'avoue qu'au début le MVC peut être vraiment déconcertant. Pendant 3 ans j'ai codé en procédural avec PHP4 et continué en PHP5. Mais dès que j'ai eu le déclic pour le MVC, j'ai vraiment vu son utilité

[meliandah]

Je n'ai jamais trop compris le MVC et pourtant j'en ai pas mal fait en DUT.
Mais si je comprend , le modèle représente ta page HTML, le squelette de la page pour être précis , et la vue représente les textes je pense. Le contrôleur il n'y en a qu'un c'est Apache du côté serveur. Par exemple j'ai conçu un objet qui me permet d'ouvrir et extraire/manipuler un fichier XML, apache s'en sert pour écrire les textes selon la langue utilisée dans les balise HTML, c'est donc ce qu'on peut appeller la vue ? Le modèle c'est le CSS/Html sans les textes et le modèle et la vue peuvent être modifié grâce à un deuxième controlleur : javascript, mais qui s'execute du côté client et doit être re-contrôler par Apache. On peut retranscrire un site en PHP en MVC un peu comme ceci non ?

[zyongh]

Je n'ai jamais trop compris le MVC et pourtant j'en ai pas mal fait en DUT.

Encore une preuve que les diplômes ne servent à rien et qu'ils ont été inventés par ceux qui rêvaient de prestige et qui n'en avaient pas les compétences. Bon on va réviser.

Mais si je comprend , le modèle représente ta page HTML, le squelette de la page pour être précis , et la vue représente les textes je pense.

Tu as absolument... pas du tout raison.
Le modèle récupère les données (d'un fichier texte, XML, d'une BDD, etc.)

Le contrôleur il n'y en a qu'un c'est Apache du côté serveur.

Tu l'as fait où ton IUT???
Apache est un serveur!!! Et rien d'autre qu'un serveur!!!
Le Controller est souvent une classe qui va traiter la requête demandée par l'utilisateur . Un modèle spécifique, choisi en fonction de la requête analysée par le Controller, va effectuer une action: par exemple chercher dans la base tous les logins dont le prénom est Robert et va les mémoriser dans des variables. Puis le Controller va choisir une Vue qui va afficher la page HTML en y insérant les données récupérées par le Model.

Par exemple j'ai conçu un objet qui me permet d'ouvrir et extraire/manipuler un fichier XML, apache s'en sert pour écrire les textes selon la langue utilisée dans les balise HTML, c'est donc ce qu'on peut appeller la vue ?

Apache n'écrit pas de texte. Il sert à interpréter du code comme PHP en interaction avec le moteur PHP. Sans serveur (Apache...) pas de PHP possible. Sans le moteur PHP, pas de PHP possible.

Le modèle c'est le CSS/Html sans les textes

Rien à voir!!! Ce n'est en aucun cas un modèle.

et le modèle et la vue peuvent être modifié grâce à un deuxième controlleur : javascript,

Le Controller n'est pas un langage de programmation (langage de prog = Javascript, PHP, Java). C'est un script programmé à l'aide d'un langage (PHP, Java).

mais qui s'execute du côté client et doit être re-contrôler par Apache. On peut retranscrire un site en PHP en MVC un peu comme ceci non ?

Jamais je ferai un IUT!!!

[Dia_FR]

hep ! j'ai fait 2 DUT (info et geii) alors doucement sur les commentaires, je mords
je suis très satisfait de ma formation personnellement, bref c'est pas le sujet

bon, histoire de pas poster juste pour dire ça, je peux que dire que effectivement tout mélanges tout et essayer de dire la même chose que zyongh

modèle : données, accès aux données, modification des données, contrôles de données............. MODELE = DONNEES

vue : code HTML (balises) associé éventuellement à du CSS (mise en page) et/ou du JavaScript (langage de script chargé et exécuté côté client), interface utilisateur.............. VUE = AFFICHAGE SANS DONNEES

contrôleur : interprétation des commandes utilisateur, partie métier, traitements, appel aux méthodes du modèle pour récupérer des données, passer des données aux vues.............. CONTROLEUR = TRAITEMENT, LIAISON MODELE-VUE

le modèle MVC est, si tu veux, une philosophie de codage, une manière de s'organiser de séparer les couches d'une application
au final, ça sort toujours des pages Web comme si tu les avais codées une par une en dur en HTML

le PHP est un langage de programmation interprété
Apache est le moteur qui permet cette interprétation

[ChriGoLioNaDor]

C'est là que tu n'as pas compris l'utilité du Controller. Tu code le controller pour qu'il analyse la requete (ce qui a été saisi dans la barre d'adresse du navigateur) et selon les valeurs dans la requete il redirige vers la page (le model) qui effectue l'action. Donc tu modifies l'objet (soit dans l'objet lui-même soit grâce à un Decorator) Et ton Controller ou ta Vue ne change pas excepté si tu dois afficher une info complémentaire dans ta Vue (une autre variable récupérée par le model par exemple.

Je pense qu'on s'est mal compris : j'ai un modèle (appelons le "menu"). Ce modèle, dans ton exemple, est utilisé sur les 100 pages du site, par le controleur de chaque page. Or, tu veux changer ton, modèle sur uniquement 30 pages. A partir de ce moment là, si tu changes ton modèle, le changement consernera TOUTES tes pages, pas juste les 30. Tu devras donc modifier ton controleur, pour qu'il appelle un autre modèle, pour les 30 pages concernées. Ou faire une condition en plus dans ton modèle, et dans ce cas, il te faudra un paramètre de plus, ce qui revient encore une fois à modifier aussi le contrôleur.
Tu ne peux pas me dire que tu vas modifier uniquement 30 pages sur 100, en utilisant le même modèle (si tu changeais de modèle, il faudra changer le controleur pour utiliser ce nouveau modèle) utilisé sur toutes les pages, sans changer les paramètres en entrée. C'est là justement mon soucis. Tout est lié, et au final tu dois souvent modifier l'ensemble modèle/controleur/vue lorsque tu as une modification à faire (rares sont les modifications du modèle, qui n'ont aucune répercution visuelles).

On se retrouve donc avec un dédoublement de classe, alors que les 2 sous classes seront inévitablement liées entre elles. Alors qu'en les assamblant, tu peux facilement faire communiquer les fonctions ensemble grâce à des variables de classe, sans avoir à passer par le contrôleur. Ainsi, ton contrôleur reste inchangé (il crée, initialise la classe, et appelle les fonctions), et si tu veux modifier une fonction pour lui ajouter un affichage, tu n'as qu'un seul fichier à modifier : celui de l'objet (regroupant modèle et vue).


Je pense que notre incompréhension vient du fait que je suis un indépendant. Bien que ma femme s'occupe du design, c'est moi qui me charge de toute la partie technique (HTML, CSS, PHP, MySQL etc). Et mon but est de trouvé un mode de développement me faisant gagner du temps! En création, et en maintenance. Or, séparer mes classes me demande un temps suplémentaire (passage par un contrôleur à modifier si je change mes paramètres, plus de fichiers à éditer et à modifier).
Je pense que le modèle MVC est plus concu pour de grosses entreprises, où il y a un intégrateur WEB qui ne s'occupe que de la mise en place du graphisme, et qui ne "veux" pas voir le code php gérant le traitement (qu'il ne comprends pas), et par la même occasion empêcher sa modification (bidouilleur, supression par inadvertance etc). De plus, chacun peut travailler en parallèle sur le même "module", ce qui ne serait pas le cas avec un fichier unique (impossible de modifer à 2 un même fichier, chacun de son coté).
Mais dans mon cas, la séparation des taches m'alourdit mon travail! Ce qu'il me faut c'est au contraire quelque chose qui me le simplifie. D'où mon intérrogation sur le MVC, mais aussi ma réticence envers les framework : je vais devoir me former (perte de production, qui se ressent directement sur mon salaire et l'efficacité de mon entreprise), et résoudre les problèmes rencontrés (recherche web, attente de correction des bugs etc). Alors qu'avec un code "maison", d'un coté il sera peut être moins poussé, moins sécurité (quoi que je fais des efforts niveau sécurité), mais il sera aussi moins lourd, beaucoup plus facilement personnalisable/entretenable, et parfaitement maitrisé.


Pour conclure, je crois que le MVC n'est vraiment pas fait pour moi, mais au moins je comprends son utilité. Pour l'anecdote, j'ai le plaisir de vous annoncer que j'ai créé mon site de e-commerce (de plus de 200 pages) en n'utilisant qu'un éditeur de texte (notepad2) pour la partie programmation. Aucun framework, éditeur (genre Webdev, dreamweaver etc)! Et forcément, le client en est très content, puisqu'il a un site parfaitement personnalisé, construit de A à Z pour lui et avec lui, et qu'il est très léger (pas de code inutile)
Si vous avez des conseils concernant la programmation php en solo, je suis preneur (par ce forum, par MP, ou par MSN ) :c'est en discutant qu'on apprends le plus, je pense

En tous cas merci à vous tous pour votre aide qui m'a bien aidé