Pattern MVC en java

[Nis]

Hello tout le monde,

Je me pose quelques questions concernant le pattern MVC. J'ai trouvé plusieurs façons de faire, et j'aimerais savoir la ou les meilleures façons de faire la chose.

Dans les tutoriels ou les méthodes qu'on m'a appris ou que j'ai lus , la séparation des couches est toujours respectées je pense, mais tout est créé différemment. Par exemple, dans une des méthodes, la classe lanceur créer le modèle et la vue, la vue crée le controller (ne serait-ce pas le controlleur qui devrait créer la vue ? Il me semble que c'est un des principes du MVC), etc ... Je ne vais pas parler de toutes ces méthodes, ça serait barbant. Tant de méthodes, et je ne sais pas laquelle est la plus propre.

Est-ce que quelqu'un pourrait m'aider ? Un bon tutoriel ?

Qui créer dans la classe lanceur, dans la vue, dans le modèle et dans le controleur ?

Pourquoi faire comme cela ? Pourquoi est-ce la meilleure façon de faire ?

Quelles interfaces créez vous ? Une interface pour chaque flèche ? : http://img527.imageshack us/my.php?image=mvcv2wz1.png

Merci d'avance pour vos réponses.

Ultimate qui désespère de trouver LA façon de faire

[Sentinel]

Le lien vers ton image est mort... Difficile de t'aider

[Nis]

Hello Sentinel ...

Effectivement ! C'est corrigé :)

[lorinc]

oukailai l'image

Est-ce que tu peux la mettre en lien, sans les balises img ?

[windu.2b]

Bonsoir,

Bon je vais tenter de répondre à tes questions, n'hésite pas à m'interrompre^W me demander pour que je précise plus...

Dans MVC, il y a en général plutôt du M-VC. C'est à dire que le Modèle est d'un côté et la Vue et le Contrôleur sont regroupés en un seul composant (ça n'est pas toujours vrai, mais en tout cas, c'est très fréquent).

Commençons par le commencement: le Modèle.

À lui tout seul, il se suffit! Il peut bosser, calculer, faire des choses, sans l'aide de personne... On peut même dire qu'il ignore presque (j'insiste sur le 'presque') l'existence des autres. C'est la partie objet-métier d'un programme: celle qui fait le vrai travail.

Ensuite, il y a le contrôleur, qui est là pour... contrôler les actions du Modèle! C'est lui qui envoie des ordres au Modèle, et ce dernier adapte son travail en conséquence (ça peut être un clic sur un bouton par exemple, qui ira dire à tel modèle de faire son action).

Enfin, il y a la Vue: elle permet de visualiser (on s'en serait douté) l'état actuel du Modèle. La Vue doit donc savoir en permanence comment évolue le Modèle. La solution la plus évidente consisterait à interroger de temps en temps le Modèle et lui demander de nous décrire son état, mais ça n'est pas une solution tip-top!

En effet, difficile de prévoir à l'avance à quelle fréquence on devra interroger le Modèle: on peut très facilement se retrouver à l'interroger trop souvent (et donc surcharge inutile de travail) ou trop peu souvent (et donc on peut rater des informations importantes).

donc pour éviter ça, on privilégie une autre solution, que l'on voit sur ton image et qui s'appelle "Change notification": le Modèle va alerter lui-même la Vue quand son état a changé.

La question est: comment le Modèle peut-il avoir connaissance de l'existence de la Vue puisqu'on a dit qu'il se suffisait à lui-même?

C'est là que le 'presque' de tout à l'heure intervient: en fait, le Modèle sait que la Vue existe... parce que la Vue aura préalablement pris soin de s'inscrire auprès du Modèle, lui demandant ainsi de l'informer de tout changement. Plus exactement, on dit que la Vue "écoute" le Modèle (on parle aussi de "listener").

Bon, ça c'était le récapitulatif (je préfère faire le point sur les concepts, histoire d'être sûr que tu comprends bien tout ce qui touche au MVC).

Maintenant voyons comment on construit le tout:

Le Modèle, on l'a vu, se suffit à lui-même. En fait, il est fréquent de donner à la vue, une référence vers le Modèle qu'elle devra écouter. ensuite, le Contrôleur et la Vue peuvent être totalement dissociés ou au contraire regroupé en un seul élément.

Prenons 2 exemples différents:

• La ProgressBar: une barre de progression affiche l'état d'avancement d'une tâche assez longue (un téléchargement, une installation...). C'est une vue car elle permet de représenter graphiquement l'état du Modèle. Mais elle ne comporte aucun Contrôleur! et pour cause, on ne peut pas agir sur l'état d'avancement de cette tâche, on la "subit".
  
• Le Slider: Le Slider est cette réglette qu'on voit dans les players audio/vidéos pour montrer l'avancement du fichier lu. Il s'agit en gros d'un point sur un trait (en soi, c'est assez proche de la ProgressBar). Ce point nous dit où on en est du film/de la musique, et c'est donc une Vue. Oui, mais... Ce point on peut le déplacer vers l'avant et vers l'arrière et ainsi agir sur la position de la "tête de lecture". C'est donc aussi un Contrôleur.
  Mieux: ce contrôleur va agir sur la "tête de lecture", qui est partie inhérente du Modèle. et ce Modèle va informer la Vue que sa position a changé! Donc la Vue va nous montrer la position du Modèle... tel qu'on vient juste de lui imposer.
  

Voilà, je sais pas si ça répond à tes questions (n'hésite pas à me flageller si besoin est)

Edit: petites retouches pour corriger les fautes d'orthographe :sorry:

[lorinc]

le must, ce serait d'étayer ta (très bonne) description avec bout de pseudo code décrivant l'exemple du slider, ou mieux, un diagrame de classe fait à la va vite (genre un export png d'umbrello ou de argouml) contenant un minimum de méthodes pour qu'on voit à peu près qui fait quoi en pratique.

[windu.2b]

Et m**** il a fallu que quelqu'un demande ce à quoi j'avais pensé en rédigeant mon commentaire, mais que je n'avais pas voulu faire par flemme

Et en plus, ça vient de lorinc

Bon, plus sérieusement, je ferai ça dans la semaine si j'ai du temps libre! Parce que c'est vrai que j'ai fait ma feignasse la dernière fois, à ne pas mettre une seule image

[Nis]

Hello tout le monde.

Tout d'abord, j'aimerais m'excuser du retard de ma réponse

Merci pour ton explication windu.2b. Je suis bien d'accord avec ce que tu écris.

Malheureusement, mon problème se situe plus au niveau de la mise en oeuvre, comme je le disais. Que créer où ?

Tout créer dans une classe "lanceur" (main), créer une partie dedans et créer le reste ailleurs, ... ?

Je me prend probablement trop le chou la dessus mais ça m'énerve de ne pas savoir si il y a une ou des méthodes priviligiées à d'autres ...

Par exemple, dans ce tutoriel : http://baptiste-wicht.developpez.com/tutor...conception/mvc/, on crée dans le main le modèle et le controlleur. Pourquoi on ne créerait pas aussi le modèle dans le controlleur plutôt que dans le main ? La façon présentée dans ce tutoriel est-elle améliorable ?

Merci d'avance pour vos réponses.

[windu.2b]

Entre temps, je me suis acheté le livre "Les cahiers du programmeur: Swing". Très bon livre, écrit par un français et qui explique comment créer une appli en Swing (appli que l'on peut voir et essayer ici

Ce livre est fort bien expliqué, clair et fournit une excellente méthode de travail, je m'en sers d'ailleurs pour réaliser une application Swing que je développe actuellement (JCaddie, pour ceux qui connaissent)

[Nis]

Je suis allé voir sur ton blog pour JCaddie, sympa :)

Je note pour le livre ... D'après la table des matières il a l'air intéressant. Y'a quelques trucs dont j'avais déjà entendu parler mais sans plus ... D'autres choses que je me demande comment faire. Et puis le fait que ça soit un logiciel développé de A à Z, c'est intéressant ...

Je pense que je vais aussi m'acheter livre "Tête la première : les design patterns" d'oreilly.

[Sentinel]

+1, la série des "Tête la première" (Head First pour l'édition anglaise) est bien faite, avec plein de schémas et d'exemples.

Excellent pour bien comprendre les concepts.

[windu.2b]

Je suis allé voir sur ton blog pour JCaddie, sympa :)

Merci

Je note pour le livre ... D'après la table des matières il a l'air intéressant. Y'a quelques trucs dont j'avais déjà entendu parler mais sans plus ... D'autres choses que je me demande comment faire. Et puis le fait que ça soit un logiciel développé de A à Z, c'est intéressant ...

Je pense que je vais aussi m'acheter livre "Tête la première : les design patterns" d'oreilly.

Pour "Design Patterns tête la première", je l'ai aussi et comme dit Sentinel, c'est un bon bouquin: bien expliqué, beaucoup de schémas, de bouts de code clairs, de diagrammes UML, de dessins "à la main" pour expliquer certains trucs... Franchement, ça change des livres où tu bouffes 600p de texte insipide

[Nis]

Vendu ! :)

Merci pour vos infos.

[fabricer]

Hello tout le monde.

Tout d'abord, j'aimerais m'excuser du retard de ma réponse

Merci pour ton explication windu.2b. Je suis bien d'accord avec ce que tu écris.

Malheureusement, mon problème se situe plus au niveau de la mise en oeuvre, comme je le disais. Que créer où ?

Tout créer dans une classe "lanceur" (main), créer une partie dedans et créer le reste ailleurs, ... ?

Je me prend probablement trop le chou la dessus mais ça m'énerve de ne pas savoir si il y a une ou des méthodes priviligiées à d'autres ...

Par exemple, dans ce tutoriel : http://baptiste-wicht.developpez.com/tutor...conception/mvc/, on crée dans le main le modèle et le controlleur. Pourquoi on ne créerait pas aussi le modèle dans le controlleur plutôt que dans le main ? La façon présentée dans ce tutoriel est-elle améliorable ?

Merci d'avance pour vos réponses.

En théorie ni le contrôleur-vue ni le Modèle n'ont d'influence sur la vie et la mort de l'un ou l'autre.

Il n'y a pas de composition ni d'aggrégation entre les deux mais une simple dépendance.

Donc en théorie l'un et l 'autre devraient pouvoir être lancés indépendamment par un programme tiers, mais sinon V-C peut se lancer et vérifier l'existence d'un modèle, si le modèle n'est pas présent elle le lance. Et plusieurs V-C lancées simultanément pourraient partager le même modèle etc...

Bref de M-VC il peut y avoir des dizaines d'implémentations différentes (et les frameworks Swing, MSForms, COCOA divergent par exemple dans les implémentations).

En fait qui lance quoi n'a pas vraiment d'importance. Si ce n'est que le controlleur et la vue doivent pour des raisons techniques (concrêtement le controlleur est un observer de la vue, il souscrit aux évènement de la vue par délégation car il doit être avertit des évènement s'y produisant) être lancés en même temps, ils sont intrinsèquement liés.

M-VC a été créé pour produire une séparation des concerns dans les programmes incluant une IHM.

*Débat personnel*

Si on respecte la séparation des concerns il ne devrait pas y avoir d'interaction directe entre le modèle et la vue. En quelque sorte le modèle c'est la mécanique business de l'application (le coeur de métier fonctionnel), la vue la représentation des informations à destination de l'humain et la gestion des rendus plus ou moins complexes mais qui n'ont pas d'impact réel sur le business, et le controlleur pilote la vue mais sert aussi d'interface entre la vue et le modèle et gère les opérations d'échange entre Vue et Model.

Il faut voir le controleur comme une interface de médiation entre la vue et le modèle ET comme une interface de pilotage de la vue. Si on n'attribue pas au controlleur la responsabilité de la médiation Model/Vue, alors différencier la vue et le controlleur n'a à mon sens pas véritablement d'intérêt car il y a alors une affinité tellement forte entre la vue et son controlleur qu'on ne trouve plus de justification à les séparer (et c'est bien ce qui arrive dans certains framework, V et C ne font alors qu'un comme dit plus haut).

Personnellement ( et c'est ma conception de M-VC, les modèles objets et les patterns sont la aussi pour être améliorés) séparer Vue et Controlleur n'a aucun intérêt si le controlleur ne joue pas le role de médiateur entre la Vue et le Model. C'est une conception personnelle que bcp partagent.

[fabricer]

Mais qu'est ce qui m'a pris de me lâcher comme ça

Je dois être fiévreux.

[Nis]

Hello,

Je vois ... Ca répond assez bien à mes questions ... du moins jusqu'à la prochaine fois où je devrai le mettre en oeuvre

Merci !