Discussion :

[unNew]

C'est gai quand on se rend compte qu'on a bien compris la chose, qu'on peut la ré-expliquer, et que les autres personnes du forum (plus doués que moi en programmation) sont d'accord avec vos propos...
;-)
;-)
Je vais passer une bonne journée, je crois...

Merci pour l'exemple je vais tacher de faire ca au plus vite.
Le principe est tres interessant, tout separer pour reutiliser et maintenir, la perfection quoi.
J'ai eu pour ma part beaucoup de difficultes a apprehender la notion de metier au depart et de la sont nes beaucoup d'interrogations mais ca vient ca vient

[avtonio]

Bonjour,

Depuis plusieurs années je travaille sur des projets d'IHM pour la gestion, et une chose dont je suis absolument certain c'est que le terme MVC est devenu très vague.

A sa création (je crois que c'était en smallTalk il y a bien longtemps) son but premier était (et est toujours) de proposer un modèle de séparation entre le modèle de données et la vue. Ceci afin de pouvoir afficher le même modèle de donnée dans plusieurs vues (swing est pour ça un bon éxemple).

Son fonctionnement était celui-là (en gros):
le model (ex: class Voiture) :
-contenir tous les champs du genre "longeur" ainsi que les accesseurs.
-lancer un évenement lors d'un changement de son état du genre "ma longeur a changer" (pour ce mécanisme, voir le pattern observer)

la vue (ex: VoitureUI):
-contenir les composants graphiques
-"contenir le model" pour l'écouter (pattern observer) et faire les modifs graphiques adéquates.
-lancer des évenements graphiques (ex: "on m'a clické dans telle zone")

le controller (ex: VoitureController)(qui a bien changé depuis..):
-"contenir" la vue pour l'écouter et "contenir" le model pour le modifier en conséquence (le but était de regrouper dans un même bloc touts les évenements de l'UI)

Depuis ça à changer,
Chaque implémentation du MVC est différente, le seul point commun est l'indépendance (+ou-) totale du modèle vis a vis de la vue.
Un changement qui me parait important(mais j'ai pas trop d'info): c'est le développement plus poussé des bibliothèques de composants.
Ces composants sachant localiser les évenement UI de façon plus précise (ex: le bouton d'un popup qui envoie "double-click") le controller tel qu'il étai pensé perd beaucoup de sa raison d'etre.
Du coup, on a le MV (qui supprime simplement le controller) et que j'aprecie beaucoup.
Mais pour la plupart des MVC actuels le controller ne sert ni plus ni moins qu'à encapsuler le doublet Model/vue afin de l'assembler à un autre doublet... (voir encore SWING)

J'espere que je ne me suis pas trop trompé et que tu comprendra mieux.
Juste un dernier mot: tu as raison de t'interroger, tout ce qui peut rendre le code industiel est le bienvenu, mais des recherches réguliéres sur te seront d'une grande aide.

A+

[Gfx]

Le concept de Model-View-Presenter semble intéresser beaucoup de monde aujourd'hui. Le MVP est justement ce dont tu parles : cette mutation du MVC pour répondre aux besoins des GUI modernes.

[calogerogigante]

Merci avtonio pour ces précisions supplémentaires...
Tes propos confirment la notion vague de controlleur...

En effet, tout ce qu'on m'a appris à l'école d'informatique sur MVC ressemblait très fort plutôt à quelque chose comme MV seulement !!

Je suis content qu'un professionnel en IHM vienne apporter cet éclaircissement qui me rassure une fois de plus, quelque part !
;-)

Gfx: ton lien est aussi très intéressant !!
Je vais l'imprimer !!

[avtonio]

merci Gfx.
On peut remarquer qu'on se rapproche de + en + de la notion de "composants abstraits" pour peu qu'on oubli le MV et qu'on s'attarde sur les conteneurs (ou composants) qui peuvent etre graphique, réseau, BDD, ou autres IO ..

Le but est biensûr de faire une API de "composants abstraits" qui pose les bases de la structure de la totalité des applications et rend le travail + industiel.
On peut penser que cette approche est utopique mais c'est faux, dans un context applicatif donné une telle API peut tout à fait subir l'épreuve du temps:
j'ai réalisé une API de ce style pour ma boite et toute l'équipe s'y est mis (et avec plaisir en plus!) il y a de cela presque 4 ans. (même si en ce moment je suis entrain d'améliorer l'API.. )

voilà, je voulai juste partager cette éxperience.

ah oui, au fait : je ne me souvient plus très bien mais il y a aussi HMVC et struts pour le web.

[Gfx]

avtonio : tu viens de décrire très brièvement l'injection de dépendance, également appelé inversion de contrôl (ou IoC en anglais pour Inversion of Control). J'ai écrit un article à ce sujet dans le numéro de mai ou juin du magazine Login: mais tu trouveras de nombreuses informations sur le web, notamment sur le site web de Martin Fowler, qui a écrit plusieurs articles à ce sujet.

[avtonio]

merci pour le lien , le peu que je viens de lire me plait.
Martin Fowler... son nom me dit qq chose...

Mais j'ai l'impression qu'on s'écarte légerement du sujet de départ. (et surtout que j'ai du boulot)
Allez, salut à tous !

[hogan]

Après lecture de ce topic une question me vient en tête : "comment le model ou la vue font pour prévenir le controller de l'arrivé d'un evenement ? ". Est ce que pour se faire ils doivent connaitre le controller !
Et dans ce cas là, faut il utiliser les écouteurs :
Et quand est il du pattern Observer !

C'est pas très clair dans mon esprit, et il me tarde de voir comment je vais implémenter MVC à mes programmes.