Discussion :

[Bertrand_g]

Bonjour,

Je ne connais pas trop MVC. En fait, je cherche plutôt à implémenter MVC2 puisque je n'ai qu'un contrôleur unique.

D'après ce que j'ai compris, le contrôleur "capte" les évènements issus de la vue. Sur ce point, pas de problème.

En revanche, comment se fait la liaison dans l'autre sens ? Est-ce qu'on peut gérer sous forme d'un pattern observateur (la vue observe le contrôleur) ? Est-ce que le contrôleur appelle directement des méthodes situées dans les objets de la vue ?

Merci d'avance pour votre aide.

Benoît

[hegros]

Le contrôleur en question, dans le pattern d'architecture MVC, est un pattern(de responsabilité).

Pour l'implémentation, en fait c'est lié à un autre pattern de responsabilité : le créateur. Qui crée la vue et qui crée le contrôleur ? Pour la vue la particularité est dans la première création puisqu'après une vue peut créer une vue donc la réponse est le contrôleur. Mais pour le contrôleur en fait cela peut être les 2.


Dans un diagramme de classe ou de package les dépendances "normales" sont plutôt de la vue vers le contrôleur(pour les attributs tandis que pour les paramètres de méthodes les dépendances dans les 2 sens sont "normales"), il est préférable d'utiliser des interfaces pour dépendances dans le meilleur des cas que se soit dans un constructeur ou une méthode de classe

[Bertrand_g]

Bonjour,

Tout d'abord, merci d'avoir pris le temps de me répondre.

Qui crée la vue et qui crée le contrôleur ? ... la réponse est le contrôleur

Ok, compris.

Mais pour le contrôleur en fait cela peut être les 2.

Pouvez-vous préciser ? Je n'ai pas bien compris cette phrase .

les dépendances "normales" sont plutôt de la vue vers le contrôleur

Autrement dit, la vue dépend du contrôleur ? La vue va faire appel à des méthodes du contrôleur ?
Pour ma part, je me suis attaché à ce que tous les évènements émis depuis la vue soient gérés par le contrôleur... Ma vue ignore tout du contrôleur.

il est préférable d'utiliser des interfaces pour dépendances dans le meilleur des cas que se soit dans un constructeur ou une méthode de classe

Désolé mais je n'ai pas bien suivi là-aussi. Un petit exemple ou un lien vers une doc ?

Benoît

[hegros]

Pouvez-vous préciser ? Je n'ai pas bien compris cette phrase .

Cela veut dire que le contrôleur peut être créer par la vue ou pas.

Code où il est créé dans la vue

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class Vue : Form, IVue
{

  private IControleur _controleur;
  public Vue()
  {
    _controleur = new Controleur();
  }

  public void ClicButton()
{
_controleur.ClicButton();
}
}

code où il n'est pas crée dans la vue mais passé en paramètre à son constructeur.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Vue : Form, IVue
{

  private IControleur _controleur;
  public Vue(IControleur controleur)
  {
    _controleur = controleur;
  }

  public void ClicButton()
{
_controleur.ClicButton();

//ou alors en passant en paramètre la vue en tant qu'interface
//c'est très courant aussi et très pratique puisque le controleur va vraiment controler la vue et lui dire quoi faire en appelant les méthodes de la vue qui vont bien
_controleur.ClicButton(this)
}
}

Autrement dit, la vue dépend du contrôleur ? La vue va faire appel à des méthodes du contrôleur ?

oui. Pour rappel le pattern contrôleur réponds à la problématique : "A qui envoyer un message provenant d'une IHM ? " La réponse est : au contrôleur. Donc oui la vue va fairfe appel à des méthodes du contrôleur.

Pour ma part, je me suis attaché à ce que tous les évènements émis depuis la vue soient gérés par le contrôleur... Ma vue ignore tout du contrôleur.

J'ai du mal à comprendre comment tu peux émettre depuis la vue des événements gérés par un contrôleur sans dépendance aucune..Avec des variables gloabales ?

Désolé mais je n'ai pas bien suivi là-aussi. Un petit exemple ou un lien vers une doc ?

Travailler avec les interfaces permets de diminuer le couplage entre couche d'une part et d'autre part de diminuer aussi les dépéndances et de les inverser (voir le I d'un ensemble de principe de conception nommé SOLID (il y a un tuto sur le site)

Dans mon exemple de code plus haut tu peux voir que j'ai une interface de controleur et une interface de vue. Pose des questions à partir de cela si cela n'est pas clair

[Bertrand_g]

Cela veut dire que le contrôleur peut être créer par la vue ou pas.

Ok.

Merci pour les exemples. C'est parfaitement clair désormais.

J'ai du mal à comprendre comment tu peux émettre depuis la vue des événements gérés par un contrôleur sans dépendance aucune..Avec des variables gloabales ?

Pour préciser les choses, je code en c++ avec wxWidgets.
Pour l'instant, j'ai créé indépendamment la fenêtre principale et le contrôleur dans la méthode "OnInit()" de mon application (l'équivalent du main). Toujours dans ce main, je lie dynamiquement les évènements générés par l'ihm à des méthodes du contrôleur. Dans le code de la vue, il n'y a pas de référence au contrôleur. Par contre, le contrôleur contient une référence vers la vue et appelle explicitement des méthodes de la vue. Je ne sais pas si c'est une bonne méthode...

Dans mon exemple de code plus haut tu peux voir que j'ai une interface de controleur et une interface de vue. Pose des questions à partir de cela si cela n'est pas clair

Cette fois, j'ai parfaitement compris ton explication.

Merci.

Benoît

[hegros]

Pour préciser les choses, je code en c++ avec wxWidgets.
Pour l'instant, j'ai créé indépendamment la fenêtre principale et le contrôleur dans la méthode "OnInit()" de mon application (l'équivalent du main). Toujours dans ce main, je lie dynamiquement les évènements générés par l'ihm à des méthodes du contrôleur. Dans le code de la vue, il n'y a pas de référence au contrôleur. Par contre, le contrôleur contient une référence vers la vue et appelle explicitement des méthodes de la vue. Je ne sais pas si c'est une bonne méthode...

Cela veut dire que tout les événements de clic bouton de la vue sont redirigés vers une méthode du contrôleur ? si je comprends bien, tu n'as aucun code dans les click des boutons de la vue ou alors du code lié à de l'affichage ?

Cela ne me semble pas si mauvais que cela. Après dans la "normalité", MVC voudrait plutôt que ta vue à une dépendance vers un contrôleur et que le contrôleur n'a pas de dépendance vers la vue. Mais vu le nombre de variante de ce pattern (qui découle lui même du pattern en couche avec pleins de variantes) ta solution est acceptable.

[Bertrand_g]

Cela veut dire que tout les événements de clic bouton de la vue sont redirigés vers une méthode du contrôleur ? si je comprends bien, tu n'as aucun code dans les click des boutons de la vue ou alors du code lié à de l'affichage ?

C'est exactement ça !

Après dans la "normalité", MVC voudrait plutôt que ta vue à une dépendance vers un contrôleur et que le contrôleur n'a pas de dépendance vers la vue.

Aïe .
L'idée est en fait de pouvoir changer de type de vue. Cela me paraît cohérent.

En fait, je me suis basé sur ce schéma : http://java.sun.com/blueprints/patte...-detailed.html. J'avais compris l'inverse.

Ceci dit, je crois que je vais m'en tenir à ma solution dorénavant si elle est "acceptable" :-).

Merci pour ton aide.

Benoît

[hegros]

Aïe .
L'idée est en fait de pouvoir changer de type de vue. Cela me paraît cohérent.

En principe la vue c'est la couche la plus haute (modèle osi présentation) les dépendances avec la couche tout de suite derrière(contrôler) vont dans les 2 sens, la communication peut être bi directionnelle il y a donc un couplage dans un sens ou dans l'autre ou dans les 2.

Donc ton implémentation (car mvc n'est pas une implémentation) est cohérente tout comme celui qui décide d'ajouter une dépendance en plus controleur vers vue.

Tu es sûr de n'avoir aucune dépendance entre ta vue et ton contrôleur ? Au moment où ton contrôleur s'abonne à un click il faut bien qu'il envoit le message à une classe de tes vues non et que ta vue appelle une méthode du contrôleur ?

Comme ce code

Code :

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

1
2
3
4
5
6
7
8
main()
{
  Vue vue; //ici une dépendance controleur vers vue
  
   Controleur controleur;

   vue.clicbutton += controleur.clickbuton(); //ici une dépendance vue vers controleur
}

En fait, je me suis basé sur ce schéma : http://java.sun.com/blueprints/patte...-detailed.html. J'avais compris l'inverse.

Sur ce schéma on voit bien que les dépendances vont dans les 2 sens, la flèche pleine et celle pointillé indique le type de dépendance (est-ce un attribut de classe, un paramètre de fonction, une variable locale, un event etc...) ce qui permet de parler de couplage plus ou moins fort.

[Bertrand_g]

Bonjour,

Je viens de lire ton message à tête reposée.

Tu es sûr de n'avoir aucune dépendance entre ta vue et ton contrôleur ?

Non, tu as raison en fait. Je suis dans la situation correspondant à ton code.

Qui plus est, je ne peux pas lier tous les évènements dans le main : certaines fenêtres (+ boutons et cie) sont créés en cours de programme et je ne peux pas les lier dès le départ comme j'ai fait jusqu'à présent. Mon approche a ses limites.

ce qui permet de parler de couplage plus ou moins fort

Si je renviens à ce que tu disais précédemment, il faut donc utiliser des interfaces pour assurer un couplage faible ?

Benoît

[hegros]

Si je renviens à ce que tu disais précédemment, il faut donc utiliser des interfaces pour assurer un couplage faible ?

C'est une approche. Pour assurer un couplage faible il faut avoir une cohésion forte au niveau de tes classes ou tes modules, ces 2 patterns (de responsabilités couplage et cohésion) travaillent ensemble.

Les interfaces (ou classes abstraites avec des méthodes virtuelles pure en c++) sont des artifices qui réduisent considérablement le couplage car tu as une dépendance uniquement vers une interface et non une multitude d'implémentation.

Par exemple si je dois créer une vue et choisit de fournir un controleur qui implémente une interface à son constructeur depuis le main.

Code :

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

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
main()
{
  IControleur controleur1 = new ControleurAppGeneral();

   Vue vue = new Vue(controleur1)

   IControleur controleur2 = new ControleurAppSpecifique();
   Vue vue1  = new Vue(controleur2);
}

public interface IControleur {}

class ControleurAppGeneral : IControleur{}

class ControleurAppSpecifique : IControleur{}

class Vue
{
   private IControleur _controleur;
   public Vue(IControleur controleur)
   {
      _controleur = controleur;
   }
}

Ce que l'on voit au niveau des dépendances du côté de la vue c'est une dépendance vers une interface donc probablement un icontroleur.hpp par exemple. Par contre c'est le main (donc dans a couche controleur) qui est plus fortement couplé avec un icontroleur.hpp puis par exemple un controleur1.hpp et controleur2.hpp pour les implémentations.


On sent bien la notion ici de composant vue et controleur. Donc pour répondre à ta question il faut avoir une approche d'architecture en composant si tu veux réduire le couplage.