Discussion :

[Baptiste Wicht]

Bonjour,

Je suis actuellement en train de développer une application (en Java, mais ca change rien) et je suis en train de me rendre compte que mon architecture est pas terrible (j'aurais mieux fait d'y réfléchir au début, mais bon ). J'ai donc décidé de revoir un peu tout ça, et de l'adapter au pattern MVC, mais je n’arrive pas vraiment à cibler tout ça...

Actuellement, j'ai :

• Des objets de données (OdXXX et OdXXXImpl) : Ce sont de simples bean formés d'accesseurs et de setters
• Des objets pour l'accès au données (OmXXX) : Ces objets me permettent d'accéder aux objets de données, c'est à dire de récupérer la liste, de faire une recherche, de récupérer un seul objet, ... Ce sont mes modèles en quelque sorte.
• Mes interfaces (JFrameXXX) : Là, je ne suis pas vraiment satisfait car elles contiennent encore un peu de code métier...
• Mes actions (actions déclenchées sur bouton ou menu) sont dans des fichiers à part et vont ensuite effectuer des traitements soit sur le métier soit sur la vue
• Mes listeners se trouvent directement dans la vue, donc pas terrible
• D'autres objets, tels que pour gérer l'exportation, la mise à jour du soft, ...

Pour le moment, il n'y a pas grand chose de très strict... Les actions font appel à des objets métiers, aux modèles et aux vues et font le transfert au bon endroit ensuite. Mais ca ne me convient pas trop en fait

Donc, ce que je vois qu'il faudrait faire déjà, il faut que je crée un objet Contrôleur qui contienne les listeners de la vue et qui ensuite la mette à jour avec les données récupérées des modèles et/ou des objets métiers.

Mais par contre, mes actions, je les mets ou ? Dans le contrôleur ? Par action, j'entends un Objet qui va exécuter quelque chose sur clic d'un bouton ou sur un menu, pour le moment elles sont dans des classes avec des accesseurs et la vue fais un actions.getActionForXXX() et la spécifie pour ce bouton. Donc soit je les mets dans un fichier à part, soit je les mets dans le contrôleur.

Et après, par exemple, une méthode qui permet de remplir les champs de vue avec les données du modèle, appelons la fillFields(), je la met où ? Directement dans la vue et elle va chercher les données dans le contrôleur, qui va ensuite chercher les données dans le modèle ? Ou alors dans le contrôleur qui va chercher les données dans le modèle et modifie les champs de la vue ?

Et une dernière question (c'est bientôt fini, vous inquiétez pas ), si la vue a besoin d'une donnée A qui est contenue dans le modèle, je mets un accesseur getA() dans le contrôleur qui va ensuite chercher la donnée dans le modèle ? Ou, une autre idée, c'est de faire un bean qui contienne les données et on mettrait ce bean dans le contrôleur et ensuite, la vue va chercher le bean dans le contrôleur et va ensuite chercher les valeurs dans le bean ? Mais c'est peut-être un peu exagéré, mais ca permettrait de ne pas avoir tous les accesseurs dans le contrôleur, qui ne ferait qu'initialiser le bean qui quant à lui ne contiendrait que des données.

D’avance de supporter cette lecture et d'essayer de répondre à mes interrogations

Si vous avez des questions, car je ne sais pas si j'ai été très clair, ben, hésitez pas

[tristan_m]

Bonjour,

Je ne suis pas vraiment un big boss de MVC, mais comme ces questions m'intéressent aussi, je me permet de remonter un peu le sujet, et de donner mes opinions.

Déjà, une page qui décrit assez bien MVC (en anglais par contre), peut être qu'elle pourra t'aider (ça a été le cas pour moi en tout cas) :
http://java.sun.com/blueprints/patte...-detailed.html


Avant de répondre (d'essayer en tout cas ) à tes questions, je tiens à préciser que je ne connais Java que moyennement donc il se peut que je passe à côté de concepts essentiels de ce langage.

Mes listeners se trouvent directement dans la vue, donc pas terrible

Un point sur lequel je ne serais pas aussi catégorique. En principe, la vue envoie les évènements aux contrôleur. C'est donc à priori la vue qui écoute les évènements. L'action du listener étant alors de prévenir le contrôleur que l'évènement est survenu.

Mais par contre, mes actions, je les mets ou ?

Je dirais que l'implémentation se fait dans le modèle, mais le rôle du contrôleur est de choisir quelle action choisir en fonction des évènements reçus. Il va traduire un ou plusieurs évènement(s) par une action à réaliser et va demander au modèle de s'en occuper.

Et après, par exemple, une méthode qui permet de remplir les champs de vue avec les données du modèle, appelons la fillFields(), je la met où ?

La question est plus sur les relations entre le modèle et la vue.
Normalement, la vue doit être une représentation du modèle. Donc les champs à remplir doivent être liés fortement à des valeurs contenues dans le modèle.
C'est à dire que théoriquement, tout changement de ces valeurs dans le modèle doit être automatiquement reflété sur la vue. (Ca se fait très bien avec le pattern Observer). Donc en ce sens, fillFields() serait une action implémentée dans le modèle, appelée par le contrôleur (suite à un évènement envoyé par la vue).
Cette méthode se contenterait de faire une notification à la vue, lui demandant de mettre à jour la valeur des champs.
J'admet que c'est un peu compliqué et du coup le nom 'fillFields' n'est pas très heureux. Mais n'hésite pas à préciser un peu si tu as l'impression que je suis à côté de la plaque par rapport à ton problème.

si la vue a besoin d'une donnée A qui est contenue dans le modèle

Je répondrais un peu de la même façon qu'à la question précédente (donc peut être à l'ouest aussi ).
Théoriquement, il n'y a aucun passage de données du modèle vers le contrôleur (cf. le schéma sur le lien que j'ai indiqué). Tout est fait par des mises à jour modèle -> vue. (encore une fois, pattern Observer).
Donc en principe, ta donnée A a une représentation dans la vue, qui est mise à jour, de façon automatique.
Bon le problème c'est que ça fait une grosse duplication des données, qui garantit certes la séparation des modèle, vue et contrôleur, mais qui prend de la place en mémoire.
Donc si des personnes plus expérimentées ont une meilleure façon de faire ou si, dans ce cas, elle n'est pas appropriée, n'hésitez pas à en faire part.


Voilà, bon comme d'hab. j'ai écrit un roman, j'espère qu'au moins quelques infos sont utiles

[Baptiste Wicht]

Salut,

Merci d'avoir répondu à ma question

Je vais regarder ça en détail ensuite et je te dirai si j'ai tout compris

[Baptiste Wicht]

J'ai lu ton roman en détail et j'ai aussi parcouru le lien que tu m'as donné (pas mal du tout soit dit en passant). Mais j'ai quand même toujours de la peine avec le contrôleur...

Je sais pas vraiment ce qu'il doit faire...

Je connais bien la distinction entre le modèle et la vue, mais j'ai de la peine avec ce Controleur. J'ai lu ça :

The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections

Donc je devrais mettre mes actions, dans le controlleur, mais le problème, c'est que j'ai aussi un peu de code métier dans certaines de mes actions... Donc ils ne devraient pas se trouver là... Par actions, j'entends une classe Action qui va effectuer quelque chose lors d'un clic par exemple.

Pour le moment, j'ai une classe Actions et je fais des getActionForXXX sur cette classe pour mettre mes actions sur mes boutons, mais c'est pas très joli... Je vais donc mettre les grosses actions directement dans des classes à part, mais je sais pas ou est-ce qu'il faut faire le lien entre l'action et le bouton par exemple...

Je pensais faire une sorte de controleur par vue, qui relierait une action à un bouton, mais qui ne contiendrait aucun code métier, tout étant contenu dans l'action dans une classe à part, ce serait viable ?

[tristan_m]

Bonjour,

Donc je devrais mettre mes actions, dans le controlleur, mais le problème, c'est que j'ai aussi un peu de code métier dans certaines de mes actions... Donc ils ne devraient pas se trouver là...

Ce que dit la phrase que tu as citée, c'est que c'est le modèle qui doit effectuer les actions. Celles-ci ne doivent donc pas se situer dans le contrôleur.
Le contrôleur sert juste d'aiguillage entre les évènements reçus (un clic par exemple) et les actions à effectuer, mais il n'exécute aucune action.

Peut être que je serais plus clair avec un exemple.
On suppose un bouton 'play' qui lors d'un clic doit lancer un fichier (musique, vidéo, etc...).

Dans la vue :
1) L'évènement 'clic' se produit
2) L'évènement 'clic' sur le bouton 'play' est envoyé au contrôleur.

Dans le contrôleur :
3) L'évènement 'clic' sur le bouton 'play' est reçu.
4) Demande au modèle d'effectuer l'action 'lanceFichier' (appeler la méthode modele.lanceFichier() )

Dans le modèle :
5) Réception de l'action 'lanceFichier'
6) Effectuer l'action 'lanceFichier'


Donc pour ton problème, je dirais que le contrôleur, c'est en fait ta classe 'Actions', qui choisit quelle action effectuer en fonction d'un évènement.
Tes classes 'Action' doivent ainsi se situer dans le modèle.
Je dirais que de façon générale, tout ce qui est susceptible de modifier les données du modèle doit se trouver dedans.

Après je ne connais pas bien la signification de 'Objet métier', mais si tu préfères éviter ou si tu ne peux pas tout regrouper dans une seule classe modèle, rien ne t'empêche de définir tes actions dans des classes séparées, auxquelles le modèle définirait des propriétés d'amitié par exemple.
La méthode lanceFichier() du modèle se contenterait alors d'appeler la méthode action.lanceFichier()

Je pensais faire une sorte de controleur par vue, qui relierait une action à un bouton, mais qui ne contiendrait aucun code métier, tout étant contenu dans l'action dans une classe à part, ce serait viable ?

Je pense que c'est effectivement le principe à mettre en oeuvre. J'y ajouterais, comme j'ai décrit précédemment, le passage par le modèle. Il est nécessaire, notamment si les données du modèle sont susceptibles d'être modifiées par ces actions (+ la notification de mise à jour à la vue le cas échéant).

Par contre, si tu me permets de pinailler un peu , je réagis sur 'un contrôleur par vue'. Un contrôleur définit le fonctionnement de l'application (mais ne l'implémente pas). Donc normalement, avoir plusieurs contrôleurs signifie avoir plusieurs fonctionnements possibles.
Rien n'interdit ça, au contraire, mais ça ne doit pas dépendre de la vue.
Dans un lecteur multimédia par exemple, appuyer deux fois sur play, ne lance pas deux fois le fichier. La deuxième fois (ça dépend du logiciel), soit il fait pause, soit il stoppe le fichier en cours de lecture et le relance, soit il ignore simplement le deuxième clic.


Voila, ba c'était le tome 2 , j'espère qu'il pourra t'éclairer un peu.
Comme je n'arrive pas à faire concis, il se peut que je ne sois pas super clair, donc n'hésite pas à demander plus de précisions.

[Baptiste Wicht]

Merci, je commence à comprendre un peu comment goupiller la chose

Ton exemple m'a bien montré les différentes interactions entre couche

Maintenant j'ai un petit doute. Disons que j'ai une classe AcUpdate :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public class AcUpdate extends AbstractAction(){
public void actionPerformed(){
//Opérations diverses
}
}

C'est donc un des mes actions. Elle doit se déclencher lors du clic dans le menu "Mise à jour". Je vais donc mettre dans le controleur une méthode getActionUpdate() que la vue va appeller pour configurer le menu. Ensuite tout le code sera dans la classe AcUpdate et rien ne sera dans le controleur ni dans la vue. Cette fois, je suis bon ?

[tristan_m]

Rebonjour,

Je dirais que tu es sur la bonne voie, mais il y a quelques détails à revoir je pense.
Le nom 'getActionUpdate' peut être trompeur.
Déjà ce n'est pas vraiment un 'get' puisqu'elle ne retourne rien à la vue.
Ensuite 'ActionUpdate' peut faire croire que la vue connait quelle action va être effectuée (ce qui ne doit pas être le cas).

Un nom du type 'clickUpdateButton' serait en ce sens peut être plus approprié.
Ou encore une méthode 'clickButton' qui prendrait en paramètre le bouton cliqué.

Sinon -ce n'est pas très explicite dans ton message-, cette méthode 'clickUpdateButton' se contente d'appeler le modèle. Ce n'est pas elle qui fera l'appel à 'actionPerformed' de ta classe.
Je vais me risquer à coder mes pensées en Java :

Contrôleur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
public void clickUpdateButton() {
modele.actionUpdate();
}

Modèle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public void actionUpdate() {
AcUpdate acUpdate = new AcUpdate();
acUpdate.actionPerformed();
notify();  // Si modifications des données du modèle possibles
}

Je pense que tu avais compris le principe, mais au cas où j'ai préféré apporter ces précisions.

[Baptiste Wicht]

En fait, c'est bien une méthode get puisqu'elle retourne à la vue une AbstractAction qui sera nécessaire à la vue pour configurer son bouton :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

bouton.setActionListener(Controlleur.getActionForBouton());

Ensuite, on n'appelle plus cette classe AcUpdate, c'est directement elle qui va s'éxécuter lors du clic sur le bouton, c'est ça le principe des Action en Java...

C'est ça qui me trouble un peu dans la conception.

[pseudocode]

Si je peux me permettre une remarque, le MVC est maintenant considéré comme un pattern de conception et plus comme un style d'architecture.

Pour votre problematique, je vous conseille de mettre 2 MVC, l'un contenu dans l'autre. Je crois d'ailleur que ce style s'appelle le M(MVC)C. A verifier.

Le MVC de 1er niveau s'occupe du comportement metier

- Modele: Les données metier

- Controleur: Les methodes metiers (qui modifient les objets de donnée)

- Vue: Tout le reste (c'est a dire la partie graphique, voir ci apres)

La vue du 1er MVC est elle meme decomposée dans un 2nd MVC

- Vue: Les widgets de votre toolkit (swing)

- Modele: Les données des widgets. C'est a dire la "conversion" des données metier en texte affichable, image, couleurs, ... dont les widgets on besoin.

- Controleur: La gestion des actions sur les Widget. Il y a alors 2 cas.

1. Une action "metier", comme la sauvegarde de modifications. Dans ce cas on appelle la methode idoine du controleur du MVC superieur

2. Une action purement "visuelle", comme la synchro entre un maitre/detail ou un Visible/Hide suivant des checkbox, ... Dans ce cas, on reste dans le 2nd MVC.

Ca donne un truc comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11


Widget (V2)  -----  Données W.(M2)  -------------- Données Metier (M1)
      \                 /                                /
        \             /                                /
         Controleur W.(C2)                           /
                   \                               /
                     \                           /
                       \                       /
                         Controleur Metier (C1)

J'emploie ce modele depuis un bout de temps maintenant, et ca marche vraiment bien. J'espere que cela vous sera utile.

[Baptiste Wicht]

Merci beaucoup. Ca m'a l'air pas mal aussi comme architecture

Je vais voir ce que je peut en faire, mais je ne pense pas adapter une telle architecture à mon application.

[tristan_m]

Bonjour,

D'abord, merci de ton intervention pseudocode, tu dois avoir une meilleure vision que moi sur Java, donc ton aide est précieuse.

Ton architecture est intéressante, elle doit répondre à pas mal de problématiques auxquelles je n'ai surement même pas encore pensé .

Par contre, le problème de wichtounet reste entier, comment associes-tu les actions aux boutons dans le 'MVC2'? Comment le controleur2 gère-t-il les actions?


A la lecture de ton dernier message wichtounet (Edit: AVANT-dernier message), je comprends un peu mieux le problème qui se pose. Effectivement j'étais passé à côté du système des actions Java.
Le problème de ces actions c'est qu'elles zappent complètement l'appel au contrôleur en cas d'évènement (puisque l'action à effectuer est définie directement sur le bouton). Donc ça casse ton architecture MVC.

Donc je dirais que pour rester dans une approche purement MVC, il faudrait que tes actions fassent simplement un appel au contrôleur.
Je m'explique :
Au moment de la création de tes boutons, tu leur fixe d'entrée une action :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
AbstractAction actionUpdate = new AcUpdate()
boutonUpddate.setActionListener(actionUpdate);

Et dans ce cas là, ton AcUpdate devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public class AcUpdate extends AbstractAction(){
public void actionPerformed(){
controller.clickUpdateButton()
}
}

L'implémentation de l'action "réelle" étant elle même codée dans le modèle (ou une classe associée, pas forcément de type AbstractAction).

Maintenant, je t'accorde que ça fait un peu usine à gaz, mais ça a l'avantage de résister si un jour tu décides d'utiliser autre chose que des actionListener.

Mais tu as peut être une meilleure solution pseudocode?

[Baptiste Wicht]

Donc je dirais que pour rester dans une approche purement MVC, il faudrait que tes actions fassent simplement un appel au contrôleur.
Je m'explique :
Au moment de la création de tes boutons, tu leur fixe d'entrée une action :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
AbstractAction actionUpdate = new AcUpdate()
boutonUpddate.setActionListener(actionUpdate);

Et dans ce cas là, ton AcUpdate devient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public class AcUpdate extends AbstractAction(){
public void actionPerformed(){
controller.clickUpdateButton()
}
}

L'implémentation de l'action "réelle" étant elle même codée dans le modèle (ou une classe associée, pas forcément de type AbstractAction).

J'y avais pensé, mais ca m'embête un peu de faire une centaine de classes contenant chacune une ligne de code...

Mais c'est vrai qu'en faisant ainsi, tu risques pas grand chose.

Je crois que ce que je vais faire, c'est mettre tout mes actions, chacune dans une classe à part (pour le moment, j'ai des classes internes et des classes) et ensuite les lier au bouton au moyen du controleur. Donc en cas de modification du type d'action, j'aurai "juste" à récupérer le code des Action et à le remettre dans le nouveau système. J'aurai certes des actions avec une ligne de code, mais il y en aura d'autres un peu plus concrètes.

[tristan_m]

Rebonjour,

C'est sur que 10000 classes qui font une ligne c'est pas top non plus.
Donc clairement tu as un choix à faire entre l'approche que tu décris (ou le contrôleur est zappé), et une approche plus MVC (ou les Actions sont quasi inutilisées), ... et peut être une meilleure qu'on a pas vu ?


Maintenant, je viens de penser à une solution à propos du milliard de classes (oui ça augmente à chaque fois ) qui ne font pas grand chose, mais de façon à peu près identique : faire une action générique, mais paramétrée.

En gros c'est faire une action ActionEvenement (dérivée de AbstractAction) qui aurait une propriété 'evenement' (renseigné à la construction par exemple), int, string ou autre.

Tout tes boutons utiliseront alors une instance de cette même classe.

Après le contrôleur aurait une méthode 'gereEvenement( evenement )' qui tracerait la route entre l'évènement et l'action à réaliser.
Du coup c'est cette fonction qui devient un peu galère à maintenir...


Bref, personellement, je ne vois pas de solution miracle, donc c'est à toi de choisir

[pseudocode]

Rebonjour,
C'est sur que 10000 classes qui font une ligne c'est pas top non plus.
Donc clairement tu as un choix à faire entre l'approche que tu décris (ou le contrôleur est zappé), et une approche plus MVC (ou les Actions sont quasi inutilisées), ... et peut être une meilleure qu'on a pas vu ?

Heu... les classes imbriquées anonymes ca ne vous convient pas ? Ou alors, j'ai pas compris le probleme ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11

public class MyClass  {
    ...
	someObject.addMouseListener(new MouseAdapter() {
            public void mouseClicked(MouseEvent e) {
	        ...//Event listener implementation goes here...
            }
	});
    ...
}

http://java.sun.com/docs/books/tutor...eralrules.html

[tristan_m]

Ah oui c'est pas mal ça!

Je ne connaissais pas du tout les classes embarquées (encore moins les embarquées anonymes d'ailleurs )

C'est spécifique à Java?
En tout cas ça a l'air bien pratique, merci de me les avoir fait découvrir!

[Baptiste Wicht]

Personnellement, je préfère utiliser des Action, et si tu réfléchis bien, c'est aussi 100 classes qui font une ligne, sauf que c'est des classes internes...


et en plus, avec ta manière de faire, si j'ai deux boutons qui font la même chose, ca me fait 2 classes avec un code égal.

[pseudocode]

Ah oui c'est pas mal ça!

Je ne connaissais pas du tout les classes embarquées (encore moins les embarquées anonymes d'ailleurs )

C'est spécifique à Java?
En tout cas ça a l'air bien pratique, merci de me les avoir fait découvrir!

Oui, c'est spécifique a Java (et aussi C# je crois). C'est carrement indispensable quand on fait du Swing sinon on se retrouve avec des classes partout. De plus, le code dans la classe embarqué peut utiliser directement les attributs de la classe principale ou les variables locales de la methode courante (a condition qu'elles soient final):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11

final JLabel label = new JLabel("attente...");
		
Timer timer = new Timer( 1000, new ActionListener() {
	public void actionPerformed(ActionEvent e) {
		label.setText("fini !");
	}
});

timer.start();

[pseudocode]

Personnellement, je préfère utiliser des Action, et si tu réfléchis bien, c'est aussi 100 classes qui font une ligne, sauf que c'est des classes internes...

et en plus, avec ta manière de faire, si j'ai deux boutons qui font la même chose, ca me fait 2 classes avec un code égal.

Oui, j'avoue que ce n'est pas du pur Objet. D'un autre coté, la conception Objet se prete assez mal a la modelisation des actions/reactions d'une IHM. Le modele le plus simple pour les IHM c'est quand meme le Form/Action.

En C#, on peut utiliser les délégués et les events, ce qui est un peu plus simple, mais nettement moins objet.

Ce qui s'en rapproche le plus en Java 5 c'est la classe imbriquée anonyme.
En java 6 on peut utiliser les langages scriptés (comme F3).

L'objet c'est bien... quand c'est approprié.

[goomazio]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
final JLabel label = new JLabel("attente...");
		
Timer timer = new Timer( 1000, new ActionListener() {
	public void actionPerformed(ActionEvent e) {
		label.setText("fini !");
	}
});

timer.start();

Bonjour,

On peut également dire que notre classe implémente ActionListener puis quand il faut spécifier l'ActionListener d'un bouton par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
JButton bouton = new JButton();
bouton.ActionName = "Bouton1"; // je ne suis plus sur que ça s'appelle ActionName
bouton.AddActionListener(this);

Et dans la méthode ActionPerformed() de notre classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if(e.actionName == "Bouton1"){
// Code à exécuter
}

C'est ce que tristan_m avait proposé je pense

faire une action générique, mais paramétrée.

En gros c'est faire une action ActionEvenement (dérivée de AbstractAction) qui aurait une propriété 'evenement' (renseigné à la construction par exemple), int, string ou autre.

Sinon, à propos de ActionListeners (contrôleur) qui trainent dans la vue, est-ce qu'on est obligé de séparer physiquement le contrôleur de la vue? En fait, c'est peut-être le principe de MVC, de séparer le code, mais en Java il y aura toujours bien une partie de contrôleur qui se balade dans la vue non?

Enfin, il y a une chose que vous n'avez pas abordé il me semble, ça doit donc être clair pour vous mais pour moi ça ne l'est pas, et j'aimerais vous poser la question : est-ce qu'il y a une manière type pour faire connaître le contrôleur à la vue? Ou le modèle au contrôleur?
Je vais restreindre ma question en donnant un exemple : pour que les actions listeners de la vue puissent appeler une méthode du contrôleur, il faut que la classe de la vue ai une référence vers ce contrôleur (pour pouvoir faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ActionPerformed(){ controleur.ActionAFaireMaintenant(); }

Il faut que l'objet controleur existe dans la vue...)

Quand on crée notre JFrame, on passe en argument la référence vers le contrôleur à la JFrame, comme-ça la JFrame pourra interragire avec le contrôleur.

Alors à ce moment là, la JFrame pourrait très bien possèder des sous-classes (une classe JPanel) qui elles-mêmes possederont des sous-classes (JPanel contiendra une classe JButton). Si les sous-classes sont plus "importantes" qu'une simple classe JButton, il se pourrait qu'on les sépare, et donc la référence vers l'objet controleur que l'on a passé à notre JFrame n'est plus accessible pour ces sous-classes. Est-ce qu'il est préférable de passer à chaque sous-classe la référence vers la JFrame, ou de passer à chaque sous-classe la référence vers la fenêtre qui instancie la sous-classe? Dans ce dernier cas, pour avoir une chance d'être compris car je m'enmèle quand j'aborde ce sujet, il faudra donc appeller une méthode du contrôleur comme-ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
// dans la classe JButton, dans un actionlistener par exemple
monPanneau.getJFrame().getControleur().MéthodeDuControleurQuonVoulaitAppeller();

Donc c'est laid, long, surement pas très logique, mais passer en paramètre la référence "Mère", la référence vers le JFrame ou le controleur lui-même, pourrait surcharger le nombre d'arguments passé aux sous-classes. Car si on doit passer le controleur mais qu'en plus on doit passer d'autres références...


Alors en résumé ( , si je me suis pas trop embrouillé) : est-ce qu'il y a un schéma type à appliquer pour que les parties du patern MVC puissent communiquer entre-elles?

D'avance merci (j'ai l'impression d'être un squatteur de post ), en espérant que ça vous intéresse aussi.

A bientôt

[Baptiste Wicht]

Désolé de te répondre si tard goomazio, mais j'avais pas vu ta question avant

Je sais pas si c'est LA technique, mais personnellement, pour que les couches puissent en découvrir une autre, j'utilise des factory. Les actions de la vue peuvent ainsi découvrir le contrôleur.

Pour ce qui est du modèle, j'essaie de limiter au minimum le code dépendant du modèle dans la vue, mais si j'en ai besoin, j'instancie le modèle ou alors je récupère le modèle à la création de la fenêtre par le contrôleur.