Pourquoi devrais-je utiliser un modèle MVC?
Il semble que tout le monde qui utilise des applications Web souhaite utiliser MVC pour tout. J'ai cependant du mal à me convaincre d'utiliser ce modèle. Je comprends que l'idée générale est de séparer la logique du backend du frontend qui représente 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 m'ajouter le contrôleur. J'ai lu beaucoup de battage médiatique sur "c'est ainsi que les applications doivent être conçues", mais peut-être que je ne comprends toujours pas ce qui est censé aller où. Chaque fois que je parle de MVC aux autres, il semble que tout le monde a 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 au lieu de séparer le frontend de la logique du backend? (La plupart des "avantages" que je vois de ce modèle sont obtenus simplement en séparant l'interface de l'implémentation, et ne parviennent pas à expliquer le but d'avoir un "contrôleur" séparé)
Il h. Martin Fowler est d'accord avec votre confusion à propos de MVC:
Je ne trouve pas terriblement utile de considérer MVC comme un modèle car il contient pas mal d'idées différentes. Différentes personnes lisant sur MVC à différents endroits en tirent des idées différentes et les décrivent comme "MVC". Si cela ne cause pas assez de confusion, vous obtenez l'effet de malentendus de MVC qui se développent à travers un système de chuchotements 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 faire une distinction claire entre les objets de domaine qui modélisent notre perception du monde réel et les objets de présentation qui sont les éléments d'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'intégralité de l'article 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ésentons-nous 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 qui, sur le plan conceptuel, doit être réalisé. Par exemple, quelles étapes dois-je franchir pour facturer un utilisateur? N.B. cela peut affecter n'importe quelle quantité d'objets, mais ne sait rien sur la façon dont ils sont conservés dans la base de données.
Voir - comment rendre le résultat?
Je pense que le problème que vous voyez est que de nombreuses applications Web sont une interface CRUD (Create-Retrieve-Update-Delete) glorifiée vers 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 où les actions que vous effectuez ne s'appliquent pas directement aux modifications du modèle, un contrôleur rend la vie beaucoup plus facile et le système plus maintenable.
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 qui utilise un contrôleur (tel que MVC) si une logique requise ne correspond pas nécessairement à un modèle (comme, par exemple, une traversée d'arbre analysant des morceaux d'URL).
Venant de CI et Yii, je pensais qu'avoir un contrôleur dédié était une idée vraiment cool. Cependant, lors du développement d'applications avec des interfaces RESTful appropriées, la nécessité d'un contrôleur pour gérer la logique non spécifique au modèle semble diminuer. Ainsi, en passant à Django puis Pyramid (dont aucun ne suit complètement l'architecture MVC), j'ai trouvé que le contrôleur n'était pas réellement un composant requis pour les applications que je construisais. Notez que les deux les frameworks ont des fonctionnalités "controller'ish", comme l'URL Dispatching dans Pyramid, mais c'est une chose de configuration, pas une chose d'exécution (comme CController dans Yii).
À la fin de la journée, ce qui est vraiment important est la séparation de la vue de la logique. Non seulement cela nettoie les choses en termes d'implémentation, mais cela permet également aux ingénieurs FE/BE de travailler en parallèle (lorsqu'ils travaillent dans un environnement d'équipe).
(Remarque: je ne développe pas d'applications Web de manière professionnelle, il peut donc y avoir quelque chose qui me manque)
Oui, la terminologie à ce sujet est un gâchis. Il est difficile d'en parler parce que vous ne savez jamais exactement ce que quelqu'un signifie par les termes.
En ce qui concerne la raison pour laquelle 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 tas 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 stub ou une maquette pour tester d'autres choses, mais lorsque vous testez votre vue concrète elle-même, c'est plus difficile. Si vous aviez un contrôleur qui ne disposait pas de widgets exécutant le même code, vous pourriez le tester directement, et peut-être pas besoin de tester les widgets via un script.
Les autres versions sont à mon humble avis plus difficiles à 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 de l'interface graphique visuelle pure de la logique qui s'applique à l'interface graphique mais ne fait pas partie du modèle commercial (des choses comme, traduire les mises à jour du modèle dans lesquelles les widgets doivent être visibles). Mais en pratique, les deux classes sont susceptibles d'être si étroitement couplées (même si elles communiquent via des interfaces) qu'il est difficile d'être trop contrarié de les fusionner en une seule vue, et de simplement garder un œil sur les façons dont la fonctionnalité pourrait être plus réutilisable s'ils étaient divisés.
Autrement dit: séparation des préoccupations. Mis à part toutes les discussions sur la façon "correcte" de faire les choses, d'avoir un code plus propre, etc., vous pouvez simplement dire que MVC vous permet de réutiliser plus facilement votre code. Fondamentalement, vous programmez vos modèles et vos contrôleurs et vous pouvez les utiliser indistinctement dans une application Web, une application de bureau, un service, n'importe où sans trop d'effort.