Architecture plus adaptée aux applications web que MVC ?

Question

J'ai appris Zend et sa structure d'application MVC pour mon nouveau travail, et j'ai découvert que travailler avec lui m'ennuyait pour des raisons que je n'arrivais pas à cerner. Puis au cours de mes études, je suis tombé sur des articles tels que MVC : Pas de solution miracle y ce podcast sur le thème du MVC et des applications web. L'auteur du podcast a présenté de très bons arguments contre MVC en tant qu'architecture d'application Web et a mis le doigt sur une grande partie de ce qui me dérangeait.

Toutefois, la question demeure : si MVC n'est pas vraiment adapté aux applications web, qu'est-ce qui l'est ?

Answer 1

Tout dépend de votre style de codage. Voici le secret : Il est impossible d'écrire un MVC classique en PHP.

Tout cadre qui prétend le contraire vous ment. La réalité est que les frameworks eux-mêmes ne peuvent même pas implémenter MVC - votre code le peut. Mais ce n'est pas un aussi bon argument marketing, je suppose.

Pour mettre en œuvre un MVC classique, il faut d'abord disposer de modèles persistants. De plus, le modèle devrait informer la vue des changements (modèle de l'observateur), ce qui est également impossible dans votre page PHP classique (vous pouvez faire quelque chose de proche du MVC classique, si vous utilisez des sockets, mais ce n'est pas pratique pour un site web réel).

Dans le domaine du développement web, il existe en fait 4 autres solutions inspirées de MVC :

• Model2 MVC : View demande des données au Modèle et décide ensuite de la manière de les rendre et des modèles à utiliser. Le contrôleur est responsable de la modification de l'état de la vue et du modèle.

• MVVM : Le contrôleur est remplacé par un ViewModel, qui est responsable de la traduction entre les attentes de la vue et la logique des modèles. La vue demande des données au contrôleur, qui traduit la demande pour que le modèle puisse la comprendre.

  Le plus souvent, vous l'utiliserez lorsque vous n'avez aucun contrôle sur les vues ou la couche modèle.

• MVP (ce que les frameworks php appellent "MVC") : Le présentateur demande des informations au modèle, les recueille, les modifie et les transmet à la vue passive.

  Pour explorer ce modèle, je vous recommande de commencer par cette publication . Il l'expliquera en détail.

• HMVC (ou PAC) : diffère du modèle 2 par la capacité d'un contrôleur à exécuter des sous-contrôleurs. Chacun d'entre eux possède sa propre triade de M, V et C. Vous gagnez en modularité et en facilité de maintenance, mais vous payez le prix d'une baisse des performances.

Quoi qu'il en soit. L'essentiel est que vous n'avez pas vraiment utilisé MVC.

Mais si vous en avez assez de toutes les structures de type MVC, vous pouvez vous tourner vers.. :

• architectures pilotées par les événements
• Architecture à n niveaux

Et puis il y a toujours le DCI mais il a quelques problèmes lorsqu'il est appliqué à PHP (vous ne pouvez pas faire un cast vers une classe en PHP pas sans de vilaines pirouettes).

Answer 2

D'après mon expérience, les avantages que vous tirez d'une architecture MVC l'emportent largement sur ses coûts et ses frais généraux apparents lorsque vous développez pour le web.

Pour quelqu'un qui débute avec un framework MVC complexe, il peut être un peu décourageant de faire l'effort supplémentaire de séparer les trois couches, et d'avoir une bonne idée de ce qui va où (certaines choses sont évidentes, d'autres peuvent être assez limites et ont tendance à être de bons sujets de discussion). Je pense que ce coût est rentabilisé à long terme, surtout si vous prévoyez que votre application va se développer ou être maintenue sur une période de temps raisonnable.

J'ai connu des situations où le coût de la création d'une nouvelle API pour permettre à d'autres clients de se connecter à une application web existante était extrêmement faible, en raison d'une bonne séparation des couches : la logique métier n'était pas du tout connectée à la présentation, c'était donc du gâteau.

Dans l'écosystème actuel des frameworks MVC, je pense que votre kilométrage peut varier considérablement, car les principes sont communs, mais il y a beaucoup de différences entre, par exemple, Zend, Django, RoR et SpringMVC.

S'il existe vraiment d'autres bonnes alternatives à ce paradigme... Je suis très intéressé par les réponses !

Désolé pour le léger mur de texte !

Answer 3

Je pense que cela dépend de ce que vous essayez de faire, personnellement. Magenta utilise MVC avec succès, et il est assez facile d'ajouter de nouvelles fonctionnalités ou de modifier celles qui existent déjà.

Bien sûr, si vous essayez de créer quelque chose de relativement simple, l'architecture MVC peut s'avérer excessive.

Answer 4

C'est une question de préférence. J'ai travaillé avec de vieilles structures comme XTemplates et Smarty et je suis maintenant passé à Codeigniter et Kohona. Je les aime beaucoup et ils fonctionnent très bien pour tout ce que je fais sur le web. Pour les applications téléphoniques, je peux également mettre en place des contrôleurs pour les fonctions nécessaires à l'extraction des données. Travaillant à la fois dans le monde Linux et dans le monde Windows, pour la création de sites Web ASP.NET, je ne vois pas d'autre moyen de créer des sites Web que d'utiliser MVC. Les projets d'applications Web dans Visual Studio sont toujours utilisés mais je préfère ne plus le faire. MVC Projects via Visual Studio est si facile à utiliser et à mettre en place. Vous pouvez faire un clic droit sur les méthodes de votre contrôleur et créer des vues automatiquement. Dans chaque structure, il y a du bon et du mauvais, mais c'est au développeur d'utiliser ce qui répond à ses besoins.