Discussion :

[TabrisLeFol]

Bonjour,
J'aimerais changer la structure de mon application en quelque chose de plus leger/modifiable. Cela fait longtemps que je connais MVC mais seulement de nom. Ayant regardé cet exemple, j'aimerais savoir l'interet du controlleur. En effet si celui doit seulement faire 'transiter' les appels de fonctions alors il s'agirait plutot d'une perte de temps....

D'avance merci

[Baptiste Wicht]

Bonjour,
J'aimerais changer la structure de mon application en quelque chose de plus leger/modifiable. Cela fait longtemps que je connais MVC mais seulement de nom. Ayant regardé cet exemple, j'aimerais savoir l'interet du controlleur. En effet si celui doit seulement faire 'transiter' les appels de fonctions alors il s'agirait plutot d'une perte de temps....

D'avance merci

C'est vrai que tu peux te passer tu controller, c'est d'ailleurs ce qui est fait souvent dans l'architecture de Swing, c'est donc plutôt une architecture M-VC.

Pour ma part, il se révèle quand même utile dans certain cas, c'est lui qui se charge de rendre les données du modèle affichable pour la couche de présentation. Il se chargera aussi de traiter les données que lui enverra l'interface graphique de manières à ce qu'elles puissent être utilisées par le modèle, mais cette problème n'existe pas toujours.

Une autre utilité est aussi le fait que tu utiliseras seulement le controlleur pour lancer ta vue et la fermer. Tu es sûr ainsi de ne pas avoir de dépendances à un framework graphique quelquonque.

Je sais pas si j'ai répondu à ta question...

[TabrisLeFol]

Ok, donc sans controlleur, je fais ecouter mes interfaces directement depuis le model et celles-ci appellent directement ses methodes.
C'est en gros ce que je faisais deja sauf que j'étais parti sur un design avec un seul listener avec beaucoup de fonctions et cela s'avere lourd a gerer.

Apres avoir un peu reflechi sur l'implementation, l'interet du controlleur serait de factoriser le peu de code commun aux interfaces (dont entre autre la recuperation des elements interessant de l'Event recu). Mais cet avantage est assez maigre dans mon cas.

Sinon d'apres ton post, le controller pourrait servir a transformer des appels models->vues et vues->model. Pourrais tu donner des exemples ?

Quant a fermer/Afficher mes vues, ce n'est pour l'instant pas mon problème. Mon application ne comporte qu'une fenetre composé d'éléments enfants toujours visible ainsi la seule chose que je dois faire est afficher ou non la fenetre principale.

[Tijee]

Les patterns servent à facilité les évolutions de ton application et le MVC n'échappe pas à ce principe : effectivement si ton application comporte une seule fenêtre et que ton code n'est pas appelé à changer un controlleur n'est pas forcément utile (encore que ça évite de surcharger les classes de ton IHM).

En revanche, imagine que tu veuilles ajouter des fonctionnalités qui te font ajouter des fenêtres, puis qu'un jour tu veuilles changer de bibliothèque graphique (genre SWT)... Tu seras bien content de n'avoir à changer que ton IHM et de conserver TOUT le reste de l'appli entièrement IDENTIQUE.

C'est un choix entre évolutivité / maintenabilité ou simplicité / rapidité.