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 ?