[Architecture MVC] Service ou controller?

Version imprimable

06/12/2014, 13h28
neperien

[Architecture MVC] Service ou controller?

Bonjour à tous,

Je suis étudiant et j'essaie de prendre le maximum de bonne pratiques pour préparer mon insertion professionnelle. J'ai un gros projet à faire en Java.
J'ai choisi de l'implementer en MVC; pour les interressés, je mettrais un lien vers un repo github public des que possible.
Le problème est le suivant : Ou mettre la logique métier d'un jeu de carte comme le Uno ? Dans un service ? Dans le controller ? Dans un modèle ?

- 1 Dans un service ?
D'apres ce que j'ai compris c'est la solution la plus propre. Un service est en quelque sorte un controller, sauf qu'il interragit avec le modele par exemple et permet le traitement de données. Super, mais comment l'instancier? Dans le main ? Avec un simple pattern singleton ?

Dans le cas du uno : que va faire le service : un tour de jeu ? Une distribution ? Ou quelque chose de plus "atomique"?

- 2 Dans un controller ?
Pourquoi pas après tout ? Solution la plus simple, que j'ai pour l'instant implementé, qui fonctionne mais qui n'a pas été accepté par le prof.

- 3 Dans un modele ?

Solution du prof.. Ai je raté un truc ??????

Merci a ceux qui repondront,
Nepe
12/12/2014, 08h25
neperien

Hello à tous,
Je comprend toujours pas.
Est ce que le controller avec l'action ActionPerformed doit être changeable facilement si l'on veut mettre une vue réseau? Est ce que le modèle peut être interchangeable ?
Comment delier l'actionListener du controller ?

Nepe
12/12/2014, 15h43
SamusStrife

Bonjour,

Il me semble qu'il y a un cours sur le MVC très bien fait sur ce site mais, pour résumer, ton prof a raison :

-Le MVC se traduit par Model, Vue, Controler : Le Model représente la partie métier de ton application, la Vue est l'interface graphique de ton application et le Controler permet de transmettre les actions effectué sur la vue vers la partie métier.

-C'est bizarre ce que tu veux faire : Pour moi le Controler ne gère aucun Listener (donc pas d'actionPerformed dans le code du controler).

- https://docs.oracle.com/javase/7/doc...tenerList.html Cet Objet te permettra de gérer plusieurs Listener dans ton model.

Maintenant on va reprendre pour ton programme en se basant sur ma façon de faire un MVC : Tu construis ta vue (donc la partie graphique de ton jeu de carte), tu rajoutes les méthodes tel que uno(); addActionListener(ActionListener listener); etc.. Dans le corps de ces méthodes, tu appelles les méthodes associé dans ton Controler (fireUno(); fireActionListener(ActionListener listener); etc..). Dans le corps de ces méthodes tu vas construire l'Event (ActionEvent dans ton cas) et transmettre le tout au Model associé => Ton Model fait son travail et grâce au EventListenerList retransmet la notifications qu'il a subit une modification aux vues implémentant tes ActionListener.

Personnellement, mes Controler sont souvent en Singleton, mais si tu veux pouvoir mettre un nouveau controler entre ta vue et ton model il te suffit juste de rajouter un setControler(Controler newControler) dans ta vue et faire les changements nécessaires.

Voila ce que je peux te dire pour l'instant, si tu veux plus d'aide il me faudrait voir ton code

Je te mets un peu de code pour que tu visualises mieux ce que je veux dire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
public class Vue{
   Controler control;
...
   public void uno(){
      control.fireUno(this);
   }
 
   public void addActionListener(ActionListener listener){
      control.fireAddActionListener(listener);
   }
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Controler{
   Model model;
...
   public void fireUno(Vue view){
      ActionEvent event = new ActionEvent(view, 0);//Met l id correspondant a l'action que tu veux faire
      model.uno();
      model.fireEvent(event);
   }
 
   public void fireAddActionListener(ActionListener listener){
      model.addActionListener(listener);
   }
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public class Model{
   EventListenerList list;
...
   public void uno(){
      //Faire le travail du Uno
   }
 
   public void addActionListener(ActionListener listener){
      list.add(ActionListener.class, listener);
   }
 
   public void fireEvent(ActionEvent event){
      for(ActionListener action : list.getListeners(ActionListener.class){
          action.actionPerformed(event);
      }
   }
}

Voici un exemple de MVC, j'espere que cela t as aidé ;)

12/12/2014, 16h52
neperien

Merci pour la réponse :D

J'ai plusieurs questions :
Si on ne met pas d'ActionPerformed dans le controller, on gère comment les entrees de l'utilisateur ?
Quel est la difference entre le pattern observable / observer & actionListener ?
12/12/2014, 17h15
SamusStrife
Mmh Je vais te donner un exemple de class qui utilise l'architecture MVC : JButton

pour ajouter un ActionListener a un JButton tu fais :

Code:

myButton.addActionListener(new MyAction());

on est d'accord?

Pour pouvoir intercepter les action de l'utilisateurs sur le bouton ca se passe ici :
Code:

1 2 3 4 5 6 public class MyAction implements ActionListener{ public void actionPerformed(ActionEvent event){ .... } }
C'est exactement ce que fait mon exemple : La class contenant ta Vue (ou dans la vue elle même si tu veux) tu définis une classe ActionListener et tu l'ajoutes a ta Vue et après, dès qu'une modification survient sur la Vue, le model le transmettra a TOUT les ActionListener qui lui ont été ajouté (et donc aux méthodes actionPerformed).

Déjà Observer et Observable sont des Interfaces qui vont définir des Objets et actionPerformed est une méthode de l'interface ActionListener (ce n'est pas pareil). Le MVC contient les pattern Observer/Observable, en effet la Vue est un Observer du Model qui lui est Observable (ces interfaces existent et tu peux les implementer aux vue et model si tu le veux) l'ActionListener quant a lui n'est qu'un écouteur (Il va écouter les actions utilisateurs et faire les actions nécessaires en fonction de l'Event) De plus il permet au modèle de notifier ses vues de divers changements (C'est a dire qu'il va dire a sa vue qui le représente, qu'il a subit un changement et la vue va l'observer pour voir les changements effectué).
12/12/2014, 21h28
neperien

8O Je captes pas... A quel moment l'utilisateur entre une donnée/clique sur un boutton ? ^^

Le JButton était un exemple (car ce composant est construit en MVC).

Après pour les actions utilisateurs, ca dépends de ton code. Mais quand tu appelles une méthode de la Vue qui a pour but de modifier le Model, le Model renvoi une notification via les Listener qui lui ont été ajouté, après si ta question est : "Comment faire pour appeler une méthode de ma Vue quand l'utilisateur appuie sur un bouton "Ok"?" Tu dois mettre un ActionListener sur ton bouton et appeler la/les méthode(s) que tu veux. Ça donnerai :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ... Vue view; JButton myButton; ... myButton.addActionListener(new MyAction()); view.addActionListener(new MyAction()); ... public class MyAction implements ActionListener{ public void actionPerformed(ActionEvent event){ if(event.getSource() == myButton){ view.uno(); }else if(event.getSource() == view){ //Do Something } } }
Normalement, tu ne peux interagir avec ton Controler que par la Vue (tu n'utilises que JButton quand tu utilises les boutons, tout comme les JTextPane ou JEditorPane, tu n'appelles jamais leurs EditorKit (Controler des JTextPane et JEditorPane)).

Après il me faudrait plus de détails : montres moi du code ou expliques moi comment il est fait. Est il entièrement en MVC ou c'est simplement quelques composants qui le sont? Gères tu les événements souris? (Si c'est le cas, ça serait plutôt par la qu'il faudrait regarder pour les actions a faire) ou seulement des boutons? Ce MVC est pour quoi exactement? Une carte? Une main? Un jeu entier?

Citation:

Envoyé par SamusStrife

Est il entièrement en MVC ou c'est simplement quelques composants qui le sont? Gères tu les événements souris? (Si c'est le cas, ça serait plutôt par la qu'il faudrait regarder pour les actions a faire) ou seulement des boutons? Ce MVC est pour quoi exactement? Une carte? Une main? Un jeu entier?

Le jeu est entièrement MVC. Je gère les cliques sur les cartes qui sont des bouttons. Le MVC est pour une partie entière. J'ai fait des choses commes :
Code:

1 2 3 4 5 6 7 8 Class TableDeJeuController implements ActionListener{ public void ActionPerformed(ActionEvent e){ MyButton b = (MyButton) e.getSource(); if(b.getCommande() == 1){ this.startGame(); // Methode contenant tout le code d'une partie } } }
Le problème est ici : une table de jeu represente une partie. Est ce que startGame() doit faire appel a un modele; ou directement manipuler du modele?

En gros des choses comme :
Code:

1 2 3 4 5 6 7 8 9 public void startGame(){ this.TableDeJeuModel.startgame(); //Ou while(!partieFinie){ this.joueur1.jouer(); this.joueur1 = nextPlayer(); } }
Merci encore du temps passé pour repondre a mes questions

D'accord je crois avoir saisi le problème.

Il faut savoir que le MVC a été conçu pour justement séparer au maximum la partie métier et la partie graphique (ca ne concerne pas que la Vue elle même mais également TOUS les composants graphique que tu vas utiliser).

Pour en revenir à ton code, le Controler a connaissance du Model et appelle les méthodes du Model directement (contrairement à la Vue qui n'a accès au Model que pour les getXXX() ). Moi personnellement j'aurai plus vu ton code comme :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
Class TableDeJeuVue implements ActionListener{ //La Vue s'occupe de TOUTE la partie graphique de ton application
 
     TableDeJeuController control = new TableDeJeuController();
 
     public void ActionPerformed(ActionEvent e){
             MyButton b = (MyButton) e.getSource();
             if(b.getCommande() == 1){
                    control.startGame(); 
              }
      }
    }

Code:

1
2
3
4
5
6
7
8
9
 
Class TableDeJeuController{
 
     TableDeJeuModel model = new TableDeJeuModel();
 
     public void startGame(){
         model.startGame(); //La tu peux appeler les méthodes de ton model directement
    }
}

Après si tu as des getters dans ton Model et que tu veux faire les choses proprement mais ce n'est pas obligatoire (je doute que ton prof t en tienne rigueur si tu ne le fais pas), je te conseil de créer tes propres Listeners pour savoir quand ton Model a été modifié (et du coup appeler les getXXX() automatiquement) ca donnerai pour les Listeners

Code:

1
2
3
4
 
public Interface TableDeJeuListener implements EventListener{
     public void play(TableDeJeuEvent event);
}

Code:

1
2
3
4
5
6
7
8
9
 
public class TableDeJeuEvent extends AWTEvent{
 
    //Rajoutes ici des public static int pour les différents ID (par exemple int aJoue = 0;)
 
    public TableDeJeuEvent(Object source, int id){
         super(source, id);
    }
}

Ce qui donnerai dans ton MVC :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
Class TableDeJeuVue implements ActionListener, TableDeJeuListener{ //La Vue s'occupe de TOUTE la partie graphique de ton application
 
     TableDeJeuController control = new TableDeJeuController();
     TableDeJeuModel model; //ne l'instancie pas, demande a ton Controler de renvoyer l'instance du Model associé a cette vue
 
     ...
     this.addTableDeJeuListener(this);
     ...
 
     public void addTableDeJeuListener(TableDeJeuListener listener){
         control.addTableDeJeuListener(listener);
     }
 
     public void ActionPerformed(ActionEvent e){
             MyButton b = (MyButton) e.getSource();
             if(b.getCommande() == 1){
                    control.startGame(this); 
              }
      }
     public void play(TableDeJeuEvent e){
         if(e.getID() == TableDeJeuEvent.aJoué){
              model.getXXX();
              //Tout ce dont t as besoin de voir du Model en gros
         }
     }
    }

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Class TableDeJeuController{
 
     TableDeJeuModel model = new TableDeJeuModel();
 
     public void startGame(TableDeJeuVue vue){
         TableDeJeuEvent event = new TableDeJeuEvent(vue, TableDeJeuEvent.aJoue);
         model.startGame(); //La tu peux appeler les méthodes de ton model directement
         //Tu dis a ton Model de notifier les Vues comme dans l'exemple que je t ai montré plus haut
    }
 
    public void addTableDeJeuListener(TableDeJeuListener listener){
         model.addTableDeJeuListener(listener);
    }
}

Et après tu fais comme dans mon exemple pour ton Model et voila ;)

EDIT : J'ai un peu modifier le code de la Vue et du Controler pour que ca colle plus a ce que j ai dit

14/12/2014, 14h55
neperien

Alors la c'est parfait. Donc en fait en résume de ce que j'ai compris : tout est événement pour découpler l'application. Jai du boulot pour repenser lapplication ! Par contre pourquoi ne pas mettre une partie de la table de jeu dans le contrôler puisquelle manipulé des modèles non ?
14/12/2014, 15h37
SamusStrife

Exactement. Alors, moi je te déconseillerai de mettre une partie de ta table de Jeu dans ton controler (que ce soit une partie graphique ou une partie métier) car ca voudrait dire que ta vue va directement modifier la partie métier (ce qui va a l encontre de la logique du MVC). Vois le Controler comme une zone tampon qui permet de dissocier le graphisme du traitement. D'ailleurs je te renvoi aux pattern Observer/Observable : n'oublie pas que la Vue n'est qu'un Observer et ne fait donc qu'Observer (ce qui implique qu'elle ne modifie rien directement).
14/12/2014, 15h45
neperien

Est ce que je montre, ou c'est différent du web ?
Pour le coup je trouve que le controller a un role extrememment petit alors que je considérais avec erreur l'inverse. Le controller doit il juste etre un pont ?
Pourquoi ne pas supprimer le controller ? Et faire des events Vue/Modele ? En résumé, a quoi le "pont" etabli par le controller sert ?
14/12/2014, 16h03
SamusStrife

Alors tu as quand même plusieurs implémentations possible du MVC (la mienne diffère un peu de celle la : mes Controlers sont en Singleton ce qui implique qu'ils peuvent gérer une infinité de Vue/Model et doivent donc, en plus, sélectionner le bon Model par rapport à la vue qui a subit une action utilisateur). Je t'ai donné un exemple mais après rien ne t empeche de mettre des Listeners dans le Controler (donc c'est lui qui écoutera les actions utilisateurs) et la vue ne sert qu'à afficher les données du Model : c'est au choix (Perso j'aime que TOUS mes composants graphique soit du coté graphique et avoir une partie "neutre" que l'on appelle le Controler ;) )

Le Controler sert, à mon sens, (car tout le monde n'a pas la même définition) a désigner le Model qui doit etre modifié, générer l event, et transmettre le tout au Model. Maintenant pour répondre plus concrètement a ta question, si tu fais un système Model/Vue (avec des Event ou non) tu vas mélanger ton graphisme avec ton code métier et cela ne respectera pas des patterns (Observer/Observable etc ce qui peut compliquer ton debug ou la transmission de ton projet a de futures équipes). Ce pont sert donc a faire abstraction entre la vue et le model. Après si tu veux voir une architecture qui donne plus de "responsabilité" au Controler regarde le PAC. La partie métier et la partie graphique sont ENTIEREMENT indépendante (et plus besoin d Event pour le coup non plus).

EDIT : Le Controler est quand même important hein même dans ma façon de faire : Ca reste un Objet primordial qui fait en sorte que le Model n'a a faire que ce qu'il a a faire et rien de plus (dans ta proposition de faire un Model/Vue avec Event soit la Vue soit le Model doit générer son Event et donc doit faire plus que ce qu'il n a a faire... Pas très propre et, du coup, peut géner a la compréhension du code). L'architecture (de façon général) impose une certaine rigueur pour coder. Pour te convaincre d'un des avantages du MVC par rapport a un Model/Vue "traditionnel", imaginons :

-Tu as une interface qui définit les Models (donc les Models héritent tous de cette interface) et dans cette interface tu mets tout tes getters
-Seul le Controler peut savoir quel Model fille tu manipules (pour des actions spécifiques selon le Model)
-La Vue quand à elle, ne connait que l'interface pour appeler les Getters ce qui fait qu'elle ne connait pas les class filles de l'interface (et elle n a pas besoin de le savoir).

maintenant ton Model/Vue :

-La Vue DOIT connaître les Models filles de l'interface pour pouvoir faire les actions spécifiques des Models (ce qui implique qu'il n y a plus aucune abstraction)
-Plus d'abstracion => code qui va vite devenir imbitable, difficile a entretenir, a comprendre et qui risque de voir son nombre de lignes augmenter de façon significative (il n'y aura plus de logique dans ton code car tout sera mélangé, ton graphisme va vite faire du métier et ton métier va vite faire du graphisme)
14/12/2014, 18h14
neperien

Okay donc je me trompe depuis le début sur MVC, c'est 100% clair maintenant :calim2:

En nouveau résumé : le controlleur permet de definir quel modèle appeller et rien d'autre. :D Je croyais vraiment qu'on pouvait se permettre de "gerer" des modèles dans le controlleur, a partir du moment ou le modele n'était pour moi que les données persistantes.

Est ce que je me suis 100% trompé, ou est ce que dans le web c'est différent (j'ai appris MVC pour le web au début) ?

En tout cas merci beaucoup, tout est clair maintenant. Je n'arrivais pas à trouver un terrain d'entente avec le prof.
14/12/2014, 19h02
SamusStrife

En fait, que ce soit web ou programmation logiciel, il ne devrait y avoir aucune différence vu que le but de l'architecture logiciel est d'être générique a tout les langages.

Pour les données persistantes (en web) c'est le modèle qui contient les requêtes SQL permettant de faire les manipulations nécessaire sur la BDD (et non le Controler, je pense que c'est ce que tu as fait) le Controler va appeler la méthode add du modele qui ne contient que la requête SQL pour ajouter un élément. En gros le Model n'est PAS la BDD mais la représente (nuance). ;)

EDIT : Tant que j'y pense vu que t as compris par rapport a mon dernier message, tu as donc compris la totalité du MVC (avec mon exemple de l'interface et ses classes filles): en effet, je l ai pas dit dés le début pour pas te perdre mais le MVC se décompose en 3 design pattern :

-l' Observateur (on ne le présente plus maintenant ;))
-Le Strategy représenté par le Controler : La Vue n'appelle qu'une méthode du Controler a chaque fois qui peut correspondre a des codes différents (appel a différentes méthodes de différents Models selon le contexte)
-Le Composite représenté par l'interface et ses classes filles : Des Objets similaires mais pas identique ayant la même base (l'interface dans l'exemple)
16/12/2014, 21h07
neperien

Désolé de rouvrir le post... Mais est ce que c'est "normal" si j'ai qu'un seul controller ? Et qu'il ne gere pas grand chose ? (grossièrement, il lance le uno, et attend que la partie se passe ... )
18/12/2014, 13h27
SamusStrife

Ca peut être normal comme non ;) tout dépend comment tu as fait ton code : Peut être que le uno() peut être factorisé en plusieurs méthodes ce qui donnerai plus de "travail" a ton controler.

Le principal quand tu utilises une architecture c'est de rester cohérent avec le code que tu produis.
18/12/2014, 21h49
neperien

Okay merci !
Je me trouve face a un nouveau probleme :
Comment attendre l'action du joueur ? Par exemple lorsqu'il doit jouer sur une carte ?

Thread.sleep marche, non ?
19/12/2014, 09h42
neperien

J'ouvre un nouveau post