Une architecture plus adaptée aux applications Web qu'à MVC?
J'ai appris Zend et sa structure d'application MVC pour mon nouvel emploi et j'ai constaté que cela me dérangeait pour des raisons que je ne pouvais pas tout à fait comprendre. Ensuite, au cours de mes études, je suis tombé sur des articles tels que MVC: No Silver Bullet et ce podcast sur le thème de MVC et des applications Web. Le gars dans le podcast a très bien argumenté contre MVC en tant qu’architecture d’application Web et a énormément parlé de ce qui me dérangeait.
Cependant, la question demeure, si MVC ne convient pas vraiment aux applications Web, qu’est-ce?
Tout dépend de votre style de codage. Voici le secret: Il est impossible d'écrire MVC classique en PHP.
Tout cadre qui prétend que vous pouvez vous mentir. 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 aussi bon argument marketing, je suppose.
Pour implémenter un MVC classique, il vous faudrait d’abord des modèles persistants. De plus, Model doit informer View des modifications (modèle de l'observateur), ce qui est également impossible sur votre page Vanilla PHP (vous pouvez faire quelque chose de similaire au MVC classique, si vous utilisez des sockets, mais c'est peu pratique pour un vrai site web).
En développement Web, vous avez en réalité 4 autres solutions inspirées par MVC:
Model2 MVC: View demande des données au modèle, puis décide comment les afficher et quels 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 échangé pour un ViewModel, qui est responsable de la conversion entre les attentes de View et la logique de Models. Afficher les données de demandes du contrôleur, qui traduisent la demande afin que Model puisse la comprendre.
Le plus souvent, vous utiliseriez cette option lorsque vous n'avez aucun contrôle sur les vues ni sur la couche de modèle.
MVP (ce que les frameworks php appellent "MVC"): le présentateur demande des informations à Model, les collecte, les modifie et les passe à la vue passive.
Pour explorer ce modèle, je vous recommande de commencer par cette publication . Cela l'expliquera en détail.
HMVC (ou PAC): diffère de Model2 par la capacité d'un contrôleur à exécuter des sous-contrôleurs. Chacun avec son propre trio de M, V et C. Vous gagnez en modularité et en facilité de maintenance, mais vous payez avec des performances inégalées.
En tous cas. La ligne du bas est: vous n'avez pas vraiment utilisé MVC.
Mais si vous en avez marre de toutes les structures de type MVC, vous pouvez vous pencher sur:
- architectures événementielles
- architecture à n niveaux
Et puis, il y a toujours le paradigme DCI , mais il a quelques problèmes lorsqu'il est appliqué à PHP (vous ne pouvez pas transtyper vers une classe dans PHP .. pas sans hacks laids).
D'après mon expérience, les avantages d'une architecture MVC dépassent de loin ses coûts et ses frais généraux apparents lors du développement pour le Web.
Pour ceux qui débutent avec un framework MVC complexe, il peut être un peu déconcertant de faire l'effort supplémentaire de séparer les trois couches et d'avoir une idée précise de ce qui appartient (certaines choses sont évidentes, d'autres peuvent être plutôt délimitées et ont tendance à être de bons sujets de discussion). Je pense que ce coût est rentable à long terme, surtout si vous vous attendez à ce que votre demande se développe ou soit maintenue sur une période de temps raisonnable.
J'ai rencontré 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 bas, en raison d'une bonne séparation des couches: la logique métier n'était pas du tout liée à la présentation. c'était du gâteau.
Dans le cadre actuel de l'écosystème MVC, je pense que votre kilométrage peut varier considérablement, car les principes sont communs, mais il existe 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!
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 des fonctionnalités existantes.
Bien sûr, si vous essayez de faire quelque chose d'assez simple, opter pour une architecture MVC peut s'avérer excessif.
C'est toutes les préférences. J'ai travaillé avec d'anciennes structures telles que XTemplates et Smarty et 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 configurer des contrôleurs pour les fonctions nécessaires à l'extraction de données. Travaillant à la fois dans le monde Linux et Windows World, pour la création de sites Web ASP.NET, je ne vois pas d'autre moyen de créer des sites Web en plus d'utiliser MVC. Les projets d'applications Web dans Visual Studio sont toujours utilisés, mais je préfère ne plus en utiliser. Les projets MVC via Visual Studio sont si faciles à utiliser et à configurer. Vous pouvez cliquer avec le bouton droit sur vos méthodes de contrôleur et créer des vues automatiquement. Dans chaque structure, il y a un bon et un mauvais mais c'est au développeur d'utiliser ce qui répond à ses besoins.