IMPLÉMENTATION DU PATTERN MVC
Tacs
Messages postés
18
Date d'inscription
samedi 15 novembre 2003
Statut
Membre
Dernière intervention
3 septembre 2007
-
10 févr. 2011 à 15:54
cs_Julien39 Messages postés 6414 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 29 juillet 2020 - 9 mai 2011 à 21:56
cs_Julien39 Messages postés 6414 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 29 juillet 2020 - 9 mai 2011 à 21:56
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/52767-implementation-du-pattern-mvc
https://codes-sources.commentcamarche.net/source/52767-implementation-du-pattern-mvc
9 mai 2011 à 21:56
Par contre, si on travail avec des personnes qui maîtrisent mal le découpage MVC, cette source apporte un vrai plus parce qu'il suffit détendre les classes pour mettre en oeuvre le design pattern et ca, c'est un vrai avantage.
Alors a utiliser surtout pour les développements web (swing est assez peu adapté) avec des pages assez simples et des équipes inexpérimentées peut apporter un plus.
12 févr. 2011 à 07:56
"Le système de notification est un peu restrictif. Si j'ai 2/3 textbox et pas mal d'éléments graphiques; la vue va, à chaque modification d'un élément, rafraîchir tout les élément." Non pas forcément, tu peux très bien créer une classe qui éténd AbstractView et qui contient un JPanel qui contient un ensemble d'éléments et ensuite l'ahouter à une JFrame, de cette manière, cette classe aura un controleur pour elle seule et la vue en entier ne sera pas remise à jour.
Mais il est vrai que cette structure est surtout commode pour les applications web qui sont assez peu dynamiques, et elle peut être vraiment contraignante pour les applications en Swing.
11 févr. 2011 à 11:10
Ce n'est pas le modèle MVC classique: La vue implémente le contrôleur (et non l'inverse) et la vue est mise à jour par le modèle (normalement optionnel, c'est le contrôleur qui devait le faire)
Ce qui fait que la vue est mise à jour dès que le modèle change; ce qui peut poser des petits problème. Le contrôleur devrait pouvoir modifier le modèle sans nécessairement mettre à jour la vue dans le cas d'opération complexes/résultats intermédiaire.
Pour moi les fonctions actionPerformed() devraient être codées dans le contrôleur (i.e le contrôleur implémente la vue, et les listeners avertissent le contrôleur des actions).
Le système de notification est un peu restrictif. Si j'ai 2/3 textbox et pas mal d'éléments graphiques; la vue va, à chaque modification d'un élément, rafraîchir tout les élément.
La vue pourrait implémenter le modèle. Dans la fonction update(), la vue se sert du IObservable pour récupérer les valeur du modèle. Je trouve ça un peu tordu.
Après, tout ça n'empêche pas que ton implémentation est tout à fait fonctionnelle.
Pour pallier à ce problème de mise à jour globale, j'essaye de faire un système de MVC hiérarchisé. I.e un MVC principal où chaque vue, modèle et contrôleur implémentent chacun respectivement une vue, modèle, contrôleur représentant un groupe d'éléments indépendant. Et ça fonctionne plutôt bien (reste à voir le cas où ces éléments ne sont finalement pas réellement indépendants :-)
PS: si tu veux une idée de ce que je veut faire, je réimplémente cette application: http://www.javafr.com/codes/MAHJONG-VRAI_43524.aspx
10 févr. 2011 à 19:42
Julien
10 févr. 2011 à 15:54
Je vais m'en servir de base pour une petite app.