MVC est-il juste le SEO de la programmation PHP?

Il y a environ un million de "frameworks PHP". Et la plupart d'entre eux se présentent comme suivant le modèle MVC. Bien qu'il soit bienvenu de surmonter le style de codage osCommerce (logique de traitement fortement mélangée avec SQL et HTML), il existe certainement des approches plus simples et plus faciles à suivre pour obtenir une conception d'application maintenable.

Le concept MVC d'origine était destiné aux applications GUI. Et pour Gtk / Python, il semble possible de le suivre en conséquence. Mais les applications Web PHP ne fonctionnent pas sur les vues en direct (éléments GUI) et sur un runtime Controller persistant. C'est très certainement un terme impropre s'il décrit simplement le regroupement de code + répertoire utilisé ou le nommage de classe.

"MVC" semble être utilisé comme un mot à la mode pour les frameworks PHP. Et j'ai en fait vu un ou deux frameworks PHP matures l'admettre, mais redéfinissant quand même l'expression pour correspondre à interna.
Est-ce donc généralement de l'huile de serpent? Pourquoi une meilleure terminologie n'est-elle pas utilisée et un concept plus sensé pour la propagation de PHP maintenable?

Quelques raisonnements élaboratifs

Pourquoi je soupçonne que les implémentations PHP ne suivent pas le vrai modèle MVC:

Modèles : en théorie, les modèles doivent être volumineux et contenir une logique métier, et les contrôleurs doivent être des gestionnaires légers (entrée-> sortie). En réalité, les frameworks PHP préconisent des modèles superficiels . CI et Symfony par exemple égalent Model == ORM. Même l'entrée HTTP est gérée par le contrôleur, n'est pas traitée comme un modèle.

Vues : solutions de contournement avec AJAX à prix réduit, il ne peut pas y avoir de vues sur les pages Web. Les frameworks PHP pompent toujours des pages. L'interface suit toujours efficacement le modèle HTTP ordinaire, il n'y a aucun avantage sur les applications non MVC. (Et enfin, aucun des frameworks php répandus ne peut en fait sortir vers des vues GUI au lieu de HTML. J'ai vu une bibliothèque PHP qui peut utiliser Gtk / Console / Web, mais pas les frameworks.)

Contrôleur : je ne suis pas sûr. Les contrôleurs n'ont probablement pas besoin d'être de longue durée et constamment actifs dans le modèle MVC. Dans le contexte du framework PHP, ce sont cependant principalement des gestionnaires de requêtes. Pas vraiment quelque chose à discuter, mais cela semble juste un peu à la mode.

Y aurait-il de meilleurs descripteurs? J'ai vu des acronymes comme PMVC ou HMVC lancés. Bien que les descriptions deviennent plus ambiguës, peut-être que celles-ci décriraient les cadres Web actuels moins hokey?

Je pense que vous regardez cela d'une manière complètement erronée. Une application graphique et une page Web sont des mondes différents, de sorte que la même définition exacte de MVC ne fonctionnera jamais pour les deux. MVC est plus sur l'idéal: séparer certaines parties de l'application comme l'affichage et la logique.

En PHP (ou sur le Web en général), une vue est la page Web elle-même: la sortie HTML. Ce n'est pas "en direct" selon votre définition, mais vous cliquez simplement sur des liens pour revenir au contrôleur (c'est-à-dire une autre demande de page).

Le contrôleur et le modèle sont là où les choses diffèrent, comme vous l'avez expliqué. En PHP, le modèle a tendance à être la couche de données, interagissant avec la base de données, etc. Mais il modélise toujours la situation, et le contrôleur contrôle toujours le flux d'application, ne serait-ce qu'une fois par chargement de page.

Le nom "Model-View-Controller" est donc parfaitement logique, bien qu'il s'agisse d'une implémentation différente dans les applications GUI et les applications Web.

Comme je ne connais pas les frameworks PHP, cela est vu d'une vue de langage de bas niveau.

Des modèles:

en théorie, les modèles devraient être gros et contenir une logique métier

C'est complètement à faire, je ne vois pas ce que PHP a à voir avec ça ...

Les modèles sont des classes de données en PHP qui pourraient probablement communiquer avec la base de données,
alors vous pourriez également envoyer le même modèle ou un modèle partiel au format JSON au client.

Je ne dirais pas la logique métier, c'est plus la logique des données (validation, interaction base de données, import / export, ...).

et les contrôleurs doivent être des gestionnaires légers (entrée-> sortie)

Vos classes Controller interagissent avec les classes Model, elles sont en effet fines.

Sur la base de la sortie, faites certaines choses avec les modèles ... Et renvoyez une ModelView au client ...

En réalité, les frameworks PHP préconisent des modèles superficiels. CI et Symfony par exemple égalent Model == ORM. Même l'entrée HTTP est gérée par le contrôleur, n'est pas traitée comme un modèle.

Je ne suis pas vraiment au courant de ces frameworks PHP ...

Mais l'entrée HTTP doit être gérée avant d'atteindre le contrôleur,
vous pouvez facilement créer une classe qui transforme les données GET et POST en bons routages et paramètres.

C'est exactement ce qui se passe dans ASP.NET MVC 2 et il n'y a rien de mal à cela,
je ne sais pas comment cela se produirait avec PHP mais je suppose que ce serait étroitement lié.

Vous pouvez même facilement transformer les données GET et POST en modèle, le modèle peut peut-être contenir une logique de constructeur pour cela. Ou certaines classes distinctes pourraient être ajoutées à cet effet.

Vues:

solutions de contournement avec AJAX à prix réduit, il ne peut pas y avoir de vues sur les pages Web. Les frameworks PHP pompent toujours des pages.

Je ne vois pas pourquoi cela n'a pas pu, la seule différence est le protocole et PHP peut retourner JSON, etc ...

Une page est votre vue et elle peut demander et mettre à jour via AJAX + JSON.
Encore une fois, je ne suis pas vraiment au courant de ces cadres PHP mais dans ASP.NET MVC 2, cela fonctionne de cette façon.

L'interface suit toujours efficacement le modèle HTTP ordinaire, il n'y a aucun avantage sur les applications non MVC. (Et enfin, aucun des frameworks php répandus ne peut en fait sortir vers des vues GUI au lieu de HTML. J'ai vu une bibliothèque PHP qui peut utiliser Gtk / Console / Web, mais pas les frameworks.)

Le seul avantage que vous obtenez (et c'est la même chose avec les applications normales) est la séparation en modèle (données) + vue (GUI) + contrôleur (logique). De même, vous ne verrez pas un framework C ++ qui peut en fait sortir en HTML ou JSON au lieu de vues GUI.

Manette:

Je ne suis pas sûr. Les contrôleurs n'ont probablement pas besoin d'être de longue durée et constamment actifs dans le modèle MVC. Dans le contexte du framework PHP, il s'agit cependant principalement de gestionnaires de requêtes. Pas vraiment quelque chose à discuter, mais cela semble juste un peu à la mode.

MVC est une architecture / un modèle logiciel, où le contrôleur s'exécute et pendant combien de temps ne correspond pas.

Mais les applications Web PHP ne fonctionnent pas sur les vues en direct (éléments GUI) et sur un runtime Controller persistant.

Non, bien sûr!

Pensez aux applications AJAX, puis la vue demande quelque chose au contrôleur et récupère une vue partielle,
cette vue ou ces données sont ensuite remplies quelque part dans la page et donc mises à jour en direct.

Le contrôleur est également persistant car vous pouvez utiliser des cookies / sessions.

"MVC" semble être utilisé comme un mot à la mode pour les frameworks PHP.

MVC est une architecture logicielle, certains frameworks peuvent l'utiliser comme un buzz, mais d'autres le font correctement ...
Voir la liste de certains frameworks sur Wikipedia .

MVC est-il juste le SEO de la programmation php?

MVC et SEO sont deux choses distinctes, mais oui ... MVC devient de plus en plus populaire.

À mon avis, l'utilisation de MVC en php amène les programmeurs sur le Web. Il est plus facile de passer par exemple de Java à PHP lorsque vous savez comment travailler avec MVC.