Pourquoi devrais-je utiliser un modèle MVC?

Il semble que tout le monde qui utilise des applications Web veuille maintenant utiliser MVC pour tout. J'ai du mal à me convaincre d'utiliser ce modèle, cependant. Je comprends que l’idée générale est de séparer la logique d’arrière-plan de l’interface représentant le programme. En règle générale, il semble que les vues dépendent toujours du contrôleur dans une certaine mesure, ce qui finit par dépendre du modèle. Je ne vois pas quel avantage l'ajout du contrôleur me procure. J'ai beaucoup entendu dire que "c'est la façon dont les applications devraient être conçues", mais je ne comprends toujours pas ce qui est censé aller où. Chaque fois que je parle de MVC à d’autres personnes, il semble que tout le monde ait une idée différente de ce qui appartient à quelle catégorie.

Alors, pourquoi devrais-je utiliser MVC? Qu'est-ce que je gagne en utilisant MVC juste en séparant le frontend de la logique du backend? (La plupart des "avantages" de ce modèle que je vois sont obtenus simplement en séparant l'interface de la mise en œuvre et ne permettent pas d'expliquer le but d'un "contrôleur" séparé)

Il h. Martin Fowler est d'accord avec votre confusion à propos de MVC:

Je ne trouve pas très utile de penser à MVC en tant que modèle, car il contient plusieurs idées différentes. Différentes personnes lisant à propos de MVC dans différents endroits en prennent différentes idées et les décrivent comme «MVC». Si cela ne crée pas suffisamment de confusion, vous obtenez alors l'effet de malentendus de MVC qui se développent à travers un système de murmures chinois.

Cependant, il continue en donnant l'une des explications les plus convaincantes de ce qui motive MVC:

Au cœur de MVC se trouve ce que j'appelle la présentation séparée. L'idée derrière la présentation séparée est de séparer clairement les objets du domaine qui modélisent notre perception du monde réel et les objets de présentation qui sont les éléments de l'interface graphique que nous voyons à l'écran. Les objets de domaine doivent être complètement autonomes et fonctionner sans référence à la présentation. Ils doivent également pouvoir prendre en charge plusieurs présentations, éventuellement simultanément.

Vous pouvez lire l'article complet de Fowler ici .

Je pense que cela dépend beaucoup du problème que vous abordez. Je vois la séparation comme suit:

Modèle - comment représente-t-on les données? Par exemple, comment passer de mes objets à un stockage persistant tel qu'une base de données -> comment enregistrer mon objet 'Utilisateur' dans la base de données?

Contrôleur - que fais-je? C’est l’action qui se déroule et ce qu’il faut faire sur le plan conceptuel. Par exemple, quelles étapes dois-je franchir pour facturer un utilisateur? Remarque: cela peut affecter toute quantité d'objets, mais ne sait pas comment ils sont conservés dans la base de données.

Voir - Comment puis-je rendre le résultat?

Le problème que je constate est que beaucoup d'applications Web constituent une interface CRUD (Create-Retrieve-Update-Delete) glorifiée avec une base de données. c'est-à-dire que le contrôleur est invité à "ajouter un utilisateur", puis il dit simplement au modèle "d'ajouter un utilisateur". Rien n'est gagné.

Cependant, dans les projets que vous accomplissez ne sont pas applicables lorsque les actions directement aux changements dans le modèle un contrôleur rend la vie beaucoup plus facile et le système plus facilement .

Tu ne devrais pas.

Permettez-moi de reformuler cela. Vous devez utiliser une architecture qui sépare la logique de vos vues. Si nécessaire, vous devez utiliser une architecture utilisant un contrôleur (tel que MVC) s'il existe une logique nécessaire qui ne rentre pas nécessairement dans un modèle (telle que, par exemple, une analyse arborescente des fragments d'URL traversant une arborescence).

Venant de CI et Yii, je pensais qu’avoir un contrôleur dédié était une très bonne idée. Cependant, lors du développement d'applications avec des interfaces RESTful appropriées, la nécessité pour un contrôleur de gérer une logique non spécifique à un modèle semble diminuer. Ainsi, lors du passage à Django, puis à Pyramid (qui ne suivent aucunement l’architecture de MVC), j’ai constaté que le contrôleur n’était pas réellement un composant requis pour les applications que je construisais. Notez que les deux frameworks ont des fonctionnalités "controller'ish", telles que l'URL Dispatching dans Pyramid, mais que c'est une chose de configuration, pas une chose d'exécution (comme CController dans Yii).

En fin de compte, ce qui est vraiment important, c'est la séparation de la vue et de la logique. Cela simplifie non seulement la mise en œuvre, mais permet également aux ingénieurs FE / BE de travailler en parallèle (dans un environnement d'équipe).

(Remarque: je ne développe pas d'applications Web de manière professionnelle, alors il se peut qu'il manque quelque chose.)

Oui, la terminologie à ce sujet est un gâchis. Il est difficile d’en parler, car on ne comprend jamais vraiment ce que quelqu'un entend par les termes.

En ce qui concerne pourquoi un contrôleur séparé, la raison peut dépendre de la version du contrôleur dont vous parlez.

Vous voudrez peut-être un contrôleur car lorsque vous exécutez des tests, la vue contient un ensemble de widgets que vous n'avez pas écrits et que vous ne voulez probablement pas tester. Oui, vous avez séparé l'implémentation de l'héritage. Vous pouvez donc utiliser un moignon ou un simulacre pour tester d'autres éléments, mais lorsque vous testez votre vue concrète, c'est plus difficile. Si vous avez un contrôleur qui ne possède pas de widgets exécutant le même code, vous pouvez le tester directement et ne pas avoir besoin de tester les widgets via un script.

Les autres versions sont IMHO plus difficile de montrer un avantage concret pour. Je pense que c'est principalement un problème de séparation des préoccupations - séparer les préoccupations d'interface graphique visuelles pures de la logique qui s'applique à l'interface graphique mais ne fait pas partie du modèle commercial (des choses telles que la traduction des mises à jour du modèle dans lesquelles les widgets doivent être visibles). Mais dans la pratique, les deux classes sont probablement si étroitement liées (même si elles communiquent via des interfaces), il est difficile de ne pas trop les mélanger pour les fusionner dans une vue, et de simplement garder un œil sur les possibilités de réutilisation des fonctionnalités. s'ils étaient divisés.

En termes simples: séparation des préoccupations. En plus de tout ce qui a trait à la manière "correcte" de procéder, à un code plus propre, etc., vous pouvez simplement dire que MVC vous permet de réutiliser plus facilement votre code. En gros, vous programmez vos modèles et vos contrôleurs et vous pouvez les utiliser indifféremment dans une application Web, une application de bureau, un service, n'importe où sans trop d'effort.

La raison fondamentale de l’utilisation d’une structure MVC apparaît dans une configuration industrielle, où un seul processus de travail consiste à suivre un modèle unique pour le développement de toute application. Ainsi, au cas où le projet passerait d'un module d'une organisation à une autre, il serait beaucoup plus facile de fournir une meilleure compréhension du scénario de travail. Il intègre la clarté du travail.
Même si, en tant qu’individu, vous avez une approche différente pour votre application, lorsque vous travaillez de manière combinée avec un associé, vous devez d’abord discuter et arriver à un modèle convenu par les deux partenaires (vous et votre associé). Et dans un tel cas, il sépare les responsabilités qui vous sont assignées et celles de votre associé avec une marge distinctive.

Je pense que MVC est utilisé comme un mot à la mode par les théoriciens qui sont des gestionnaires. Cependant, cela dit, l'itération actuelle du Web avec une conception réactive très répandue en HTML5 et la tentative de créer une seule ligne de programmation de base de données pouvant fonctionner sur le Web et sur un iPhone se prêtent parfaitement aux idées générales de MVC. La technologie Web frontale évolue littéralement à la vitesse de la lumière avec Jquery, de nouvelles itérations de contrôle CSS, alors que le côté serveur de la chose évolue à la vitesse d'un escargot.

En fin de compte, tout sur le serveur ne sera en réalité que des services ou des "applets" qui pomperont des données vers le serveur frontal et, selon le type de client que vous possédez, ces données seront utilisées et affichées différemment. En ce sens, MVC a du sens.

À cet égard, je crois que dans le monde réel actuel, le MVVM est vraiment un meilleur "motif" ou ce que vous voulez appeler un contrôleur, car un contrôleur doit toujours revenir au modèle pour changer la vue, ce qui est lent. . Dans le modèle MVVM, ViewModel peut donner des mises à jour immédiates à la vue. De plus, le modèle MVVM favorise les principes de conception RESTful, à mon humble avis.