Interprétation idéale de l'architecture MVC
Quelle est la meilleure approche ?

Le , par alatox, Membre du Club
Bonjour,

J'essaye de depuis quelques temps de comprendre le principe du MVC.
J'ai donc suivi des tutoriaux sur le net et me suis documenté.

Ce message s'adresse donc aux personnes ayant lu le livre "Swing" de la collection "les cahiers du programmeur" publié chez eyrolles.

p167 est présenté un diagramme de classe MVC dit idéal puis p175 un diagramme de classes simplifié.

Quel aurait été le diagramme de classe MVC idéal avec les classes HomeController, FurnitureController, et CatalogController (p175)?

Par ailleurs, il me semble avoir compris que les MVC permettait de rendre les couches indépendantes et j'ai du mal saisir pourquoi c'est au contrôleur d'instancier la vue, pouvez vous m'expliquer ?. (J'aurais plutôt la vue être instanciée ailleurs et passée au contrôleur ensuite)

Ensuite, si je désirais rajouter une base de données. Les interrogations à cette dernière interviendraient dans quelle entité du MVC ? (Je ferais ça dans le modèle mais je vois bien aussi le contrôleur le faire et ensuite le passer au modèle qui ne serait finalement plus qu'un cache)

Merci d'avance pour vos réponses.


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de PanicKernel PanicKernel - Membre régulier http://www.developpez.com
le 08/09/2009 à 10:56
Csperandio, je crois qu'on est d'accord
Avatar de csperandio csperandio - Membre régulier http://www.developpez.com
le 08/09/2009 à 11:19
Citation Envoyé par PanicKernel  Voir le message
Csperandio, je crois qu'on est d'accord



Je trouve par contre que l'intégration du design pattern Delegate est quelque fois un peu lourd en Java (et tout langage assez stricte dans la déclaration des types).
Je pense que c'est plus agréable et moins verbeux avec des langages comme ObjC, Ruby, Groovy, Python & Co.

Quelques fois, on veut utiliser un objet delegate et on sait qu'un seul message lui sera envoyé. En Java, on est obligé de lui ajouter toutes les méthodes dépendantes de l'interface :/ C'est sans doute plus "propre" mais plus lourd. C'est mon avis.
Avatar de PanicKernel PanicKernel - Membre régulier http://www.developpez.com
le 08/09/2009 à 11:30
Citation Envoyé par csperandio  Voir le message

Quelques fois, on veut utiliser un objet delegate et on sait qu'un seul message lui sera envoyé. En Java, on est obligé de lui ajouter toutes les méthodes dépendantes de l'interface :/ C'est sans doute plus "propre" mais plus lourd.

En java, on utilise communément des classes adapter qui implémentent un interface avec du code vide, comme cela il suffit d'hériter de l'adapter et de redéfinir les methodes liées aux evts effectivement traités. En plus avec les classes anonymes, c'est concis d'implémenter une gestion d'évt.
Avatar de csperandio csperandio - Membre régulier http://www.developpez.com
le 08/09/2009 à 11:35
Citation Envoyé par PanicKernel  Voir le message
En java, on utilise communément des classes adapter qui implémentent un interface avec du code vide, comme cela il suffit d'hériter de l'adapter et de redéfinir les methodes liées aux evts effectivement traités. En plus avec les classes anonymes, c'est concis d'implémenter une gestion d'évt.

Merci pour cette information
Mais, il ne peut pas avoir de souci par le manque d'héritage multiple ?

Ma question est purement théorique
Avatar de alatox alatox - Membre du Club http://www.developpez.com
le 08/09/2009 à 17:37
Effectivement, on ne peut hériter que d'une seule classe en java (et c'est déjà bien suffisant). Donc, soit on sait que notre classe n'aura pas besoin de dériver d'une autre que l'adapter et on utilise ce dernier, soit on doit faire avec les toutes les méthodes qui composent (ce que je ne trouve pas si contraignant)

Puisque j'y suis, j'ai ouvert une discussion sur les bonnes pratiques concernant le mappage d'une base de données et je vous invite à y participer : http://www.developpez.net/forums/d80...-schema-objet/
Avatar de Hephaistos007 Hephaistos007 - Membre expert http://www.developpez.com
le 02/02/2010 à 18:17
L'interprétation idéale de l'architecture MVC, c'est de ne pas parler de développement Web ! Si il y a bien un terme qui a été vidé de sa substance, c'est bien celui là, avec l'arrivée du développement Web.

Pour rappel, le pattern MVC est issu du monde SmallTalk et repose fondamentalement sur une orientation objet. Ensuite, c'est un pattern, et en tant que tel, il offre une solution à un problème : celui d'assurer une corrélation/interaction entre les données d'une part, et les vues sur ces données d'autre part. Une communication par événements fait souvent office de glue pour tout cela.

Les tutoriels fleurissent de toutes parts sur les frameworks MVC en PHP, en JAVA, en Ruby, etc. Leurs auteurs ne s'étonnent même pas de l'architecture MVC qu'il nous présentent fièrement. Ci-dessous un exemple qui nous est proche :
http://c-maneu.developpez.com/tutori...intro/#LII-B-2
Pourtant, on y voit clairement qu'un modèle peut notifier la vue de ses changements. En effet, il semble pertinent que la mise à jour des données implique de rafraîchir toutes les vues sur lesdites données. Or, il est totalement impossible de porter ce principe au développement Web ! En outre, la difficulté des auteurs à définir ce que contient précisément un contrôleur (en général un fourre-tout) aurait du leur mettre la puce à l'oreille sur cette terrible méprise.

Du coup, de quoi parlent tous ces tutoriaux ? Et bien tout simplement d'un meilleur découpage de l'application pour faciliter l'évolutivité et la maintenance du code. A ce titre, ces frameworks ont du mérite. Mais de grâce, arrêtons de parler de MVC là ou il n'y en a pas, cela évitera aux novices bien des écueils.
Avatar de benwit benwit - Rédacteur http://www.developpez.com
le 03/02/2010 à 8:48
@Hephaistos007, dans l'ensemble, ce que tu dis est juste.

Néanmoins, j'aimerai apporter trois bémols.

Citation Envoyé par Hephaistos007  Voir le message
Or, il est totalement impossible de porter ce principe au développement Web !

Ceci n'est pas vraiment exacte car avec du push serveur (comet, ...) il est possible de faire de la notification d'évènement du serveur vers le client.
Je t'accorde cependant que c'est encore rare.

Citation Envoyé par Hephaistos007  Voir le message
arrêtons de parler de MVC là ou il n'y en a pas, cela évitera aux novices bien des écueils.

Pour un puriste, je t'accorde que c'est énervant. Maintenant, on peut présenter des adaptations de MVC (sans une application à la lettre). Par exemple, je trouve des points communs (sans y ressembler toutefois) avec l'architecture en couche (M~Accès aux données et traitement métier, V~Présentation de ces données et C~Action de contrôle) car ils ont en commun un même intérêt, celui de présenter la séparation des responsabilités.

Et pour finir, 3° point, si le MVC est difficilement applicable au client/serveur (sans communication bidirectionnelle), il peut exister à différents niveaux.
Exemple, avec GWT, techno client centric, tu peux faire du vrai MVC uniquement côté client (même si pour ma part, j'y trouve quelques inconvénients)
Avatar de Hephaistos007 Hephaistos007 - Membre expert http://www.developpez.com
le 04/02/2010 à 21:29
Je suis tombé tout bêtement sur cette remarque accessible sur le site officiel de struts :
Citation Envoyé par http://struts.apache.org/primer.html#mvc
The term "MVC" originated with the SmallTalk Model-View-Controller framework. In Smalltalk MVC, the View updates itself from the Model, via the "Observer" pattern. The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.

But, a direct link between the Model and the View is not practical for web applications, and we modify the classic MVC arrangement so that it would look less like a loop and more like a horseshoe with the controller in the middle.

Avatar de Patriarch24 Patriarch24 - Membre expérimenté http://www.developpez.com
le 05/02/2010 à 9:59
Le problème comme le dit Hephaistos007 c'est que MVC est un terme devenu plus ou moins générique pour désigner un ensemble de modèles différents (MVC, Document-Vue, MVP, MVPM, ...). Il existe énormément de stratégies différentes, appelées MVC par abus de langage.
De fait, il n'existe pas un "MVC idéal", mais le modèle MVC, et les autres. Avec des stratégies différentes (Vue Passive, Contrôleur de Supervision, etc.).

Pour plus d'infos : http://martinfowler.com/eaaDev/ dans la section "Presentation Patterns".
Avatar de tse_jc tse_jc - Membre confirmé http://www.developpez.com
le 15/06/2013 à 0:03
Bonjour,

Permettez-moi d'apportez ma pierre à l'édifice.

Déjà le développement web n'est rien d'autre qu'un environnement client serveur en réseau avec un serveur tiers : Client - serveur tiers - DB. C'est minimaliste mais c'est une architecture qui ne s'étends donc pas au simple environnement web.

Elle reste particulière car elle impose des contraintes techniques supplémentaires influant directement les performances d'une application développée pour une telle structure d'environnement. Donc appliquer un pattern (ou version de pattern) incompatible ou non optimisé pour un tel environnement juste pour le principe de montrer qu'on sait le faire n'a aucun sens ni aucun intérêt.
C'est un peu comme si on concevait une voiture pour une utilisation autre que celle dont on a besoin.

Et pour finir, 3° point, si le MVC est difficilement applicable au client/serveur (sans communication bidirectionnelle), il peut exister à différents niveaux.

Je reste un peu dubitatif sur cette phrase. Si c'est au sens réseau, une communication non bidirectionnelle n'a pas de sens. Si c'est au niveau applicatif, si le contrôleur interroge le modèle ou donne un ordre au modèle en principe il y a toujours une réponse, elle est donc à ce titre toujours bidirectionnelle. S'il s'agit que le contrôleur reçoive un ordre du modèle (au sens du push serveur évoqué dans la réponse), je me permet de rappeler que dans un tel contexte "web" le contrôleur n'a pas d'ordre à recevoir du modèle, car c'est son rôle d'en donner et de contrôler les flux. L'utilisateur peut le requêter à travers la vue ou à travers le front controller. D'où le modèle évoqué du MVC2 adapté à cet environnement et dans lequel le contrôleur joue un rôle central pour rester efficace et performant. Donc en fonction de la réponse du modèle à un ordre du controller, le controller saura quelle mesure adopter pour respecter les contraintes et la logique métier applicative et s'il doit par exemple plutôt laisser la décision à l'utilisateur.

Ensuite pour la question de faire communiquer la vue et le contrôleur via une gestion évènementielle afin de coupler faiblement la vue du contrôleur, sauf à mettre le client sur le serveur, cela est sans intérêt est contre performant et productif en client serveur web. Donc à partir du moment où le client devient distant du serveur, afin d'optimiser les échanges et la bande passante la vue doit être en mesure d'évaluer la nécessite d'interroger le controller et savoir précisément qui et comment interroger sur le serveur pour faire son travail. La vue et le contrôleur doivent donc être fortement liés pour être efficaces. Le getview() sur le contrôleur est légitime car c'est à lui d'instancier la vue pour la fournir au client si il est nécéssaire de le faire pour éviter de surcharger le réseau, et lui seul à les outils pour en juger.

En ce qui concerne instancier un contrôleur à partir d'une vue pour gérer une vue partielle, tout dépends le contexte, mais dans un contexte "dev web" faut arrêter un peu et rester raisonnable quand à la granularité de la gestion objet appliquée à la vue. Si on va par là où doit-on mettre la limite et à quel titre? doit-on mettre un contrôleur derrière chaque caractère d'une phrase pour en gérer sa vue? ça n'a pas de sens. Une vue doit se limiter à une fenêtre applicative (sans instanciation de contrôleur partiel) et bannir la fenêtre qui fait tout du style usine à gaz: faut se limiter aux contraintes métier et s'y tenir et savoir adapter les besoins applicatifs à l'environnement d'utilisation au niveau maîtrise d'ouvrage.

Voilà ++
Avatar de tse_jc tse_jc - Membre confirmé http://www.developpez.com
le 15/06/2013 à 18:57
Bonjour,

Je vais compléter ma réponse car elle peut paraître incomplète voir inexacte en certains endroits.
En MVC dans un contexte "web" pour garder un langage vulgarisé et le même que celui abordé dans le post initial, il faut bien comprendre que le cahier des charges initial est d'optimiser la bande passante (on ne requête sur le réseau lorsque cela est absolument nécessaire) tant en quantité de requête qu'en contenu. Cela permet entre autre choses d'augmenter la capacité de charge et de gestion concurrentielle de l'applicatif, donc cela reste un minimum syndical si je puis dire.

Dans ce contexte ce n'est pas au contrôleur central de gérer la vue qu'il a instancié (attention: à ne pas prendre au sens objet du terme) car cela n'est pas son rôle. Par contre il fournit au client le contrôleur de la vue qui lui est associé (gestion interaction IHM au niveau client), généralement développé en Javascript dans le contexte évoqué initialement. On peut donc dire que c'est le contrôleur de la vue situé au niveau client qui va dialoguer avec le contrôleur central et non la vue directement.
Dans cet architecture, le serveur ne peut faire confiance à ce qui provient du client, il est donc déraisonnable de faire communiquer le modèle et la vue directement ne serait-ce qu'en lecture seule. C'est le travail primaire du contrôleur central de vérifier la légitimité, l'intégrité et le contenu des requêtes qu'il reçoit afin de les transmettre au modèle. C'est un impératif qui oblige au niveau du modèle.

Bon week-end à tous.

Jc.
Offres d'emploi IT
Data scientist inspection générale (H/F)
Société Générale - Ile de France - Hauts-de-Seine
Architecte de données (H/F)
Société Générale - Ile de France - Ile de France
Data engineer H/F
Safran - Ile de France - Magny-les-Hameaux /Saclay

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique ALM