Discussion:Modèle-vue-contrôleur

fusion avec l'article Model View Controller Oz 4 jul 2005 à 10:47 (CEST)

Je viens de rajouter une catégorie "exemple". L'idée est de presenter des exemples de MVC en précisant le modèle, la vue et le controlleur.

Certaines entrées dans la catégorie pourraient être déplacées dans cette catégories ?

Djedi 10 novembre 2006 à 09:40 (CET)

Pourquoi Struts n'apparait-il pas dans les exemples ? Grimko

Ajoutez le. Djedi

Le MVC n'est pas réellement un patron de conception contrairement à ce qui est indiqué, je me suis fait dézingué quand j'ai sorti ça à ma prof de génie logiciel :-)

Utilisation native en Swing

Ce paragraphe mériterait d'être un sous titre du paragraphe des exemples je crois... non ? -- Mab (d) 26 janvier 2008 à 17:26 (CET)

FAUX

Je tiens à signaler que l'article est faux. Il suffit de lire les articles de Reenskaug (cités en fin d'article). Le modèle est juste, mais la vue ne gère en gros que les affichages et le contrôleur est le lien entre l'utilisateur et le système. En outre il s'occupe de presque toutes les entrées. Ce qui est présenté avec un composant qui s'occupe des entrées et sorties et un autre qui fait le lien entre ceci et le modèle, c'est le modèle PAC. http://iihm.imag.fr/publs/1987/Interact87.PAC.pdf Tom (d) 11 mars 2008 à 14:48 (CET)

Je confirme que cet article est totalement faux. Il est d'autant plus faux que certaines références sont elles même fausses.

Le modèle MVC décrit ne correspond pas au modèle MVC original. L'article est en totale contradiction avec l'article anglais Model–view–controller - Wikipedia 147.161.182.127 (discuter) 27 octobre 2021 à 17:13 (CEST)

• Discutez dans les chapitres prévus.
• Liens utiles : À recycler - À traduire - À fusionner - Orthographe à vérifier - Soupçons de copyright - Articles non neutres

Proposé par :Tom (d)

Raisons de la demande de vérification

Il y a une confusion dans le contenu (cf page de discussion). En effet le modèle décrit sous le nom MVC est en fait le modèle PAC. C'est d'autant plus grave que l'on retrouve l'erreur fréquemment sur le net, et même dans des cours, voire des thèses ! Il est pourtant facile de vérifier les informations.

• http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html : description originale de MVC par son concepteur
• http://iihm.imag.fr/publs/1987/Interact87.PAC.pdf : article original de PAC

Discussions et commentaires

Toutes les discussions vont ci-dessous. Je propose de s'inspirer de l'article anglais, L'article français semble centré sur certaine applications alors que l'article anglais décris le MVC de manière plus générale.

Mise à jour de la vue après modification du modèle

«	Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle et ensuite avertit la vue que les données ont changé pour qu'elle se mette à jour.	»

D'après mes souvenirs, et en regardant le schéma qui introduit le modèle MVC dans cet article, il me semble que c'est plutôt le modèle qui avertit la vue d'un changement dans ses données, plutôt que le contrôleur. Sinon, toujours en se basant sur les interactions illustrées par le même schéma, si le modèle est modifié par une autre "application", la vue est désynchronisée, et le contrôleur associé n'est manifestement pas "prévenu". 82.123.87.47 (d) 26 juin 2008 à 18:02 (CEST)

Ce schéma ne signifie rien, ce n'est pas de l'UML et il n'y a pas de légende. Le modèle est normalement un objet de type serveur et il ne devrait donc pas être source d'interaction. C'est justement le rôle du contrôleur de se positionner entre les "données" et les "applications", son rôle est d'informer toutes les vues qu'une modification a été, va être, ou potentiellement être réalisée sur une "donnée". Ce pattern nécessite un enregistrement d'une vue intéressée par une donnée quelconque auprès du contrôleur de cette donnée (Guff pattern Observer ou Java Listener). De même, toute "application" ou "vue" modifiant une donnée doit en informer son contrôleur (système coopératif). --Nipou (d) 8 juillet 2008 à 03:25 (CEST)

Si le schema ne signifie rien, il faut l'enlever.

Le modèle n'est pas un objet de type serveur dans le MVC original. Le rôle du contrôleur n'est pas d'informer les vues qu'une modification a été faite. Le modèle notifie directement les vues. 147.161.182.127 (discuter) 27 octobre 2021 à 17:07 (CEST)

Et Microsoft.NET ???

Dans les exemples d'architecture MVC, il serait bon d'ajouter les frameworks disponible en .NET :

• Monorail
• MVC.NET

-Bardamu-78.155.158.60 (d) 7 janvier 2009 à 11:52 (CET)

• Discutez dans les chapitres prévus.
• Liens utiles : À recycler - À traduire - À fusionner - Orthographe à vérifier - Soupçons de copyright - Articles non neutres

Proposé par : 92.143.136.193 (d) 17 février 2011 à 04:42 (CET)NULL

Raisons de la demande de vérification

pas clair et pas défini + contradiction dans le propos (injection de dépendances)

Discussions et commentaires

Toutes les discussions vont ci-dessous.

Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web, bâties à partir de serveurs d'applications. Des couches supplémentaires sont alors introduites ainsi que les mécanismes d'inversion de contrôle et d'injection de dépendance2.

Inexact : l'injection de dépendances n'est en aucun cas liée au MVC. Ce sont des notions totalement distinctes. On peut faire de l'injection sans MVC. En effet, l'injection désigne simplement le fait par exemple qu'un utilisateur puisse mettre du code dans un formulaire (dans le cas d'un formulaire de contact ou de recherche par exemple) qui sera executé à la validation du formulaire pouvant ainsi réaliser les actions voulues par l'utilisateur. C'est ainsi un moyen de piratage d'une certaine maniére, mais trés facilement détournable grâce à des fonctions comme mysql_real_escape_string par exemple pour les requetes Sql.(Thosaw) Différence avec l'Architecture trois tiers[modifier]

---

Juste pour corriger cette remarque: son auteur confond l'attaque par injection de code (Injection de code dans les applications web) avec les design patterns Injection de dépendances et Inversion de contrôle. Mais il faut dire que la phrase sur les limites est mal tournée. Et quand on voit le nombre de frameworks MVC nés pour le web, c'est là que j'ai envie d'écrire "Inexact" à mon tour... --82.67.110.51 (d) 2 février 2013 à 01:11 (CET)

• Discutez dans les chapitres prévus.
• Liens utiles : À recycler - À traduire - À fusionner - Orthographe à vérifier - Soupçons de copyright - Articles non neutres

Revoir la présentation du modèle MVC. Proposé par : Agua (d) 4 février 2012 à 21:57 (CET)

Raisons de la demande de vérification

Le modèle MVC n'est pas un IHM, seule la partie V(ue) du modèle MVC est l'IHM.

Discussions et commentaires

Le modèle MVC est en fait un modèle complet couvrant une application informatique. La partie V(ue) est l'IHM (interface homme-machine) permettant à l'usager de communiquer avec l'application et ainsi de créer des évènements déclencheurs de traitements. Ces évènements sont transmis à la partie C(ontrôleur) du modèle qui est la partie "intelligente" sachant quel traitement apporter en conséquence de l'évènement. Ce faisant, le C(ontrôleur) sollicite si besoin est la partie M(odèle (de données)) du modèle MVC pour obtenir/mettre à jour les informations complémentaires dont il a besoin pour effectuer les traitements voulus. La partie M(odèle de données) gère tout accès aux données, que ce soit en lecture ou en mise à jour. Ainsi organisée, l'application devient très clairement analysée et facilement programmable, en particulier dans un paradigme orienté objet, où la compartimentation étanche de la programmation est déjà très accentuée.

Exemples d’architecture MVC

La liste des exemples d'architectures MVC est régulièrement supprimée et rétablie. Des ajouts d'exemples ont été réclamé plusieurs fois dans la page de discussion. Et il semble légitime de voir l'application d'un concept dans une réalisation concrète dans un langage familier. On peut éventuellement discuter de la pertinence de créer une page spécifique à cette section.

Concernant, la remarque de Kyro "Manque de pertinence et de surcroit de source.". Il apparait qu'une majorité des exemples (mais pas tous) pointent vers une page Wikipedia décrivant l'exemple cité et présisant qu'il implémente le MVC. A l'inverse, l'exemple comme ASP.NET fait référence à la page wikipedia. Mais il n'y est pas question du Pattern MVC. D'autres exemples sont donnés sans aucune référence.

Qt ne s'appuie pas sur MVC mais sur Model/view. Il suffit de regarder la documentation officielle. — Le message qui précède, non signé, a été déposé par l'IP 87.88.224.19 (discuter), le 31 janvier 2022 à 11:28 (CET)

C'est retiré. 90.34.122.217 (discuter) 24 février 2022 à 15:32 (CET)

Suppression de Inconvénient

Aucun inconvénient n'était listé dans la partie

Pertinence du modèle ?

Note : Cette partie de la discussion a été purement et simplement supprimée (2 fois...), sans aucune explication. Merci de bien vouloir argumenter avant de procéder à des suppressions ! La page de discussion est là pour exprimer des points de vue, et si celui qui est mentionné ici est véritablement gênant, c'est peut-être qu'il tient un fond de vérité ! Je remets donc le texte initial... et merci de le laisser, vous n'êtes pas le propriétaire de cette page !

"L'inconvénient pratique du MVC, c'est que ses différents promoteurs ne sont pas d'accord entre eux sur les différents rôles et interactions des trois composants entre eux. Il en résulte des utilisations très curieuses, où le premier souci du développeur semble être de tourner la difficulté en rapatriant au maximum tous ses algorithmes dans la vue, et où finalement le MVC n'est plus qu'une difficulté un peu obscure.

Neuf fois sur dix, concrètement, personne ne comprend rien au MVC. A chaque fois que je pose la question autour de moi (le MVC en fait, qu'est-ce que c'est ?) à des programmeurs non spécialistes, j'obtiens des réponses gênées, vagues et embrouillées. Le présent article ne fait pas exception à la règle. Il est tout simplement incompréhensible. "L'organisation d'une interface graphique est délicate" : ah bon ? Et en quoi le MVC va-t-il la rendre plus facile ? Mystère...

Comparons la complexité de la chose avec un schéma classique : avec un MVC, vous en êtes encore à essayer de comprendre l'implémentation, alors que le programme est déjà terminé avec une architecture traditionnelle simple, du type "display-event-process". Pour la maintenance, c'est encore pire : faites la modification, et vous croisez les doigts ; seul le concepteur est capable de s'y retrouver, et encore, à condition que le programme ne soit pas trop vieux.

Le problème majeur qu'il y a à vouloir isoler l'interface, les données, et les traitements, c'est qu'on ne peut pas concevoir une fenêtre correctement si l'on ne connaît pas les données, on ne peut pas traiter ces mêmes données sans connaître leur description, et le modèle existe de toutes façons dans la description de la BDD. Dans la pratique des implémentations réalisées, on se retrouve avec un programme éclaté en au moins deux morceaux, avec du bruit entre les deux, et des problèmes supplémentaires à régler.

A croire que les concepteurs n'utilisent pas leurs propres outils !"