Discussion :

[womannosky]

Bonjour à tous,

J'ai lu sur un site que pour établir l'architecture MVC de façon optimale, il fallait que ces trois parties du programme ne communique que par le biais d'interface. Je ne comprends pas bien comment s'est possible.

De plus, pour moi, le controlleur ressemble plus à une interface qu'à autre chose. Pouvez vous m'en dire plus à ce sujet ??

Merci à tous !

[Invité]

Tu peux détailler plus précisément les points qui te semblent obscurs ?

Voire décrire le cas qui t'intéresse (type d'application, etc...) parce qu'il y a plusieurs manières de voir et d'implémenter un modèle MVC.
(Ca sera pas pareil par exemple pour une appli web que pour une appli desktop)

[womannosky]

Je voudrais juste savoir comment faire pour que le modèle, le controlleur et la vue peuvent communiquer entre eux que par le biais d'interfaces. C'est plus une question générale qu'une question de code bien précise.
Je n'arrive pas à comprendre comment ces trois éléments en Java pourrait communiquer ainsi.

[Invité]

Quand on dit "communiquer par interface" ça veut dire que tout ou partie de ces composants doivent être des classes implémentant des interfaces.

Mettons que j'aie une classe de Modèle :

Code :

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

1
2
3
4
5
public class ModelImpl implements Model {
    public void bouga() {
        System.out.printl("Appel de bouga avec l'implémentation ModelImpl");
    }
}

Avec Model l'interface suivante :

Code :

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

1
2
3
public interface Model {
    public void bouga();
}

Ensuite, le but c'est de faire en sorte que la Vue et le Contrôleur ne connaissent QUE le nom de l'interface. Par exemple imaginons que lors du clic sur un bouton le contrôleur décide d'appeler la méthode bouga :

Code :

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

1
2
3
4
5
6
7
8
9
10
public class Controller {
 
    Model model; // Le contrôleur a une référence vers un objet de type Model
                 // mais on ne sait pas quelle implémentation sera utilisée
 
    public void actionPerformed() {
        model.bouga(); // Appel de la méthode bouga, toujours sans connaitre
                       // l'implémentation
    }
}

Après il faut voir quand se fera l'instanciation de l'objet ModelImpl et par qui.

L'intérêt c'est de pouvoir remplacer ModelImpl par une autre classe, une autre implémentation très facilement si on décide que le modèle doit se comporter différemment.

[womannosky]

Merci pour ta réponse, ça me parait un peu moins confus à présent.
Dans ce mode d'architecture, le controlleur et la vue ont une référence sur un objet modèle, ok mais est-ce que il en est de même pour la classe Modele, dispose-t-elle de référence vers un objet Vue et Controlleur ?

[jojodu31]

non le modèle dispose généralement d'écouteurs sur le controleur qui enverra des notifications à son modèle

[Invité]

Perso tel que je le vois le Modèle est une couche sous-jacente par rapport aux autres. Ce sont les couches Vue et Contrôleur qui y accèdent. Le modèle lui-même ne devrait pas faire d'appel aux autres parties.

Perso je pense que la meilleure manière d'implémenter le modèle MVC c'est de laisser le principal rôle au contrôleur. C'est à dire :

1. L'utilisateur fait une action (clic sur un bouton, etc.)
2. Le contrôleur reçoit la requête du client.
3. Le contrôleur détermine en fonction quel sera l'action que le modèle devra exécuter.
4. Le contrôleur appelle la méthode voulue du modèle et reçoit les résultats.
5. Le contrôleur fait appel à la bonne vue en fonction des résultats renvoyés par le modèle.
6. Le contrôleur affiche la vue au client.

En gros pour moi il faut que ce soit toujours le contrôleur qui appelle les autres parties du programme, La vue ne devant jamais appeler le contrôleur ou le modèle, le modèle ne devant jamais appeler la vue ou le contrôleur.

Après peut-être que la manière d'implémenter le MVC peut différer suivant le type d'application qu'on veut développer. Il est probable que pour un jeu video on interprétera le modèle MVC différemment par rapport à une appli de gestion.
De même ça variera probablement en fonction des technologies utilisées (appli desktop ou appli web).

[womannosky]

tu pouvais pas faire plus clair jojodu31, lol.
Désolé mais avec une phrase correcte, je comprendrais peut être mieux, merci !
Tu veux dire que le Modele dispose d'une référence sur un objet Controlleur et c'est tout ? rien sur la Vue ? Et c'est qu'après les infos renvoyées par le Modele au Controlleur que le Controlleur les renvoie à la Vue ?

[jojodu31]

petit tuto utile MVC

[womannosky]

Ok kei2906, je comprends mieux le principe, maintenant, je pense que la Vue peut éventuellement appeler le Modele pour récupérer certaines données supplémentaires, non ?
Ma remarque n'est peut être pas judicieuse car celà rajoutera une dépendance entre la Vue et le Modele, ce qui n'est pas favorable à l'application, je sias pas trop...

EDIT: Merci pour le tuto.

[Invité]

Comme je disais, on peut interpréter le modèle MVC différemment.

Dans le tuto (plutôt bien fait d'ailleurs) que nous montre jojo, on voit un modèle MVC bien adapté aux applis desktop (avec une interface swing par exemple).
Ce que je présente, c'est plus adapté aux applis web (une servlet étant chargée de faire le contrôleur).

La principale différence venant du fait que pour une appli web on n'a en général que des pages statiques, alors que dans une appli desktop la vue peut plus facilement se mettre à jour toute seule (d'où les requêtes d'état et notifications de changement qu'on ne pourra pas avoir dans une appli web).

[womannosky]

Je vois. Merci pour vos réponses !