[Design Pattern] Modele MVC

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/08/2005, 22h06
unNew

[Design Pattern] Modele MVC

Bonjour,
En MVC, il y a la partie CLIENT, la partie CONTROLEUR et la partie METIER donc :

client <---------> controleur <---------> Metier

Si je modifies quelque chose côté métier je devrai aussi le faire côté client en cas d'abscence du controleur.
Alors que en présence justement du controleur, je ne toucherai pas au client, les quelques modifications eventuelles seront faites au niveau de ce controleur.

Certes la logique est interessante mais j'avoue que concretement, je ne vois pas vraiment ce qu'on met dans le Metier et ce qu'on met dans le controleur.
Vous aller me dire que dans le metier on place les classes metiers. Oui mais j'ai encore un peu de mal a apprehender cette notion. Classes metiers? Mais concretement!!!!!!

Un peu d'eclaircissement seraient les bienvenu.
Merci beaucoup.
17/08/2005, 08h25
calogerogigante

Oui, on dit aussi Modèle-Vue-Controlleur.

Le modèle est par exemple une classe qui se charge de fournir à tout instant comment on doit concrétiser le modèle à partir de ses données. Ou, dit autrement, cette classe décrit de quoi est constitué le modèle, et quelle est la valeur de ses données à l'instant présent.

La vue est par exemple une classe qui se charge de présenter les données du modèle (c'est pas forcément l'écran uniquement, mais souvent).

Et le controlleur est une classe qui vérifie tout changement fait sur les données du modèle. Et qui (en cas de changement donc) en avertit immédiatement la "vue", pour y faire un rafraîchissement (ou un update simplement).

Si tu veux, je peux te donner un exemple java simple complet là-dessus...

EDIT : L'inverse est aussi vrai pour le controlleur et la vue. Si l'utilisateur utilise la vue pour modifier les données du modèle, le controlleur doit avertir le modèle que la vue a été changée (et donc le modèle doit mettre à jour ses données par rapport à la vue changée).
17/08/2005, 10h35
viena

Dans la pratique, et pour commencer, je te conseille de reflechir de cette facon :
Ton modele (metier comme tu l'appeles) doit fonctionner sans le reste. Je m'explique : imagine que tu dois faire ton application en mode texte, en sortie console (System.out.println...). Et bien, si tu fais cela, tu auras pratiquement ton modele.
Ensuite :
les system.out.println, c'est la vue (le client) et les vérifications de ce qui a été saisie par l'utilisateur au client pour savoir que faire (un menu par exemple "tapez 1 pour..."), c'est le controleur.
Bon, en réalité c'est un peu plus compliqué que cela, mais en reflechissant de cette facon tu t'approche du bon concept.
Bon courage. :wink:
17/08/2005, 22h06
unNew

Citation:

Envoyé par viena

Ton modele (metier comme tu l'appeles) doit fonctionner sans le reste. Je m'explique : imagine que tu dois faire ton application en mode texte, en sortie console (System.out.println...). Et bien, si tu fais cela, tu auras pratiquement ton modele.
Ensuite :
les system.out.println, c'est la vue (le client) et les vérifications de ce qui a été saisie par l'utilisateur au client pour savoir que faire (un menu par exemple "tapez 1 pour..."), c'est le controleur.
Bon, en réalité c'est un peu plus compliqué que cela, mais en reflechissant de cette facon tu t'approche du bon concept.
Bon courage. :wink:

Bonjour,
La vue oui je vois bien, pas de souci!

En fait j'essai absolument faire le tri dans mon crane entre ce qui va dans le controleur et ce qui va dans le modele.
L'image que tu presentes ci dessus est interessante mais elle tend a vouloir signifier que le modele interagit avec la vue, ce qui n'en est rien, puisque le modele passe obligatoirement par le controleur.
Les system.out.println seraient plutot, si on suit ton image ce que devront retourner les methodes des classes du modele vers le controleur.

Qu'en penses tu?
17/08/2005, 22h13
unNew

Citation:

Envoyé par calogerogigante

Oui, on dit aussi Modèle-Vue-Controlleur.

Le modèle est par exemple une classe qui se charge de fournir à tout instant comment on doit concrétiser le modèle à partir de ses données. Ou, dit autrement, cette classe décrit de quoi est constitué le modèle, et quelle est la valeur de ses données à l'instant présent.

La vue est par exemple une classe qui se charge de présenter les données du modèle (c'est pas forcément l'écran uniquement, mais souvent).

Et le controlleur est une classe qui vérifie tout changement fait sur les données du modèle. Et qui (en cas de changement donc) en avertit immédiatement la "vue", pour y faire un rafraîchissement (ou un update simplement).

Si tu veux, je peux te donner un exemple java simple complet là-dessus...

EDIT : L'inverse est aussi vrai pour le controlleur et la vue. Si l'utilisateur utilise la vue pour modifier les données du modèle, le controlleur doit avertir le modèle que la vue a été changée (et donc le modèle doit mettre à jour ses données par rapport à la vue changée).

bonjour,
ca ne serait pas de refus merci.

En fait je crois que c'est une question de vocabulaire, les classes metiers j'ai du mal a apprehender le terme.

Prenons l'exmple d'un interfacage avec une base de donnees.
La vue pas de souci, un client leger classique.
Il y aura aussi les classes ou on mettre les methodes qui permettent par exemple de faire des Select dans la base.
Ca serait le controleur non?
Et le model que serait il alors?
Merci[/b]

OK, c'est parti pour l'exemple... J'ai trouvé ça quelque part sur internet, y'a plus de 2 ans, et je trouve que c'est la meilleure illustration du modèle MVC qu'on peut trouver...

PgmCercle.java : c'est la classe principale contenant la méthode main :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
/** Pgm Cercle : illustration de l'approche modèle-vue = observer = publish and subscribe;
*/
 
public class PgmCercle extends JFrame  {
 
	Cercle cercle = new Cercle(50);	// le modèle de données
	PanelVue1 pVue1 = new PanelVue1(cercle); // la 1ère vue
	PanelVue2 pVue2 = new PanelVue2(cercle); // la 2ème vue
	PanelVue3 pVue3 = new PanelVue3(cercle); // la 3ème vue
 
	// programme principal
	public static void main(String args[]) {
		PgmCercle f = new PgmCercle();
		f.setSize(400,400);
		f.setVisible(true);
	}
 
	// constructeur de la fenêtre
	public PgmCercle() {
 
		this.setTitle("illustration de l'approche modèle-vue");
 
		// ajout des 3 vues
		this.getContentPane().add(pVue1, BorderLayout.NORTH);
		this.getContentPane().add(pVue2, BorderLayout.CENTER);
		this.getContentPane().add(pVue3, BorderLayout.SOUTH);
 
		// fermeture de la fenêtre
		this.addWindowListener(new WindowAdapter() {
			public void windowClosing(WindowEvent e) {
				System.exit(0);
			}
		});
 
	}// fin du constructeur
 
} // fin de la classe

Ensuite, voici la classe qui représente le modèle de données : ici, c'est la gestion d'un cercle

Cercle.java

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
import java.util.Vector; 
import java.awt.event.*;
 
public class Cercle {
 
	private int rayon;
	private Vector vecteur;
 
	// constructeur
	public Cercle(int rayon) {
		setRayon(rayon);
	}
 
	// méthode qui permet d'ajouter un listener.
	public synchronized void addActionListener(ActionListener l) {
		Vector v = vecteur == null ? new Vector(3): (Vector) vecteur.clone();
		if (!v.contains(l)) {
			v.addElement(l);
			vecteur = v;
		}
	}
 
	// méthode qui permet de retirer un listener.
	public synchronized void removeActionListener(ActionListener l) {
		Vector v = (Vector) vecteur.clone();
		v.removeElement(l);
		vecteur = v;
	}
 
	// getter
	public int getRayon() {
		return rayon;
	}
 
	// setter
	public void setRayon(int rayon) {
		this.rayon = rayon;
		notifierListeners(new ActionEvent(this, ActionEvent.ACTION_PERFORMED,
														"rayon"));
	}
 
	// méthode qui notifie les listeners.
	protected void notifierListeners(ActionEvent e) {
		if (vecteur==null) return;
		for (int i=0; i<vecteur.size(); i++) 
			( (ActionListener) vecteur.elementAt(i) ).actionPerformed(e);
 
	}
 
} // fin de la classe

Les 3 sources suivantes sont les vues qui gèrent la présentation du modèle cercle sous 3 forme différentes (ici, dans 3 panels différents).

Les controlleurs sont parfois souvent imbriqués avec la source vue (c'est le cas dans mon exemple):

cf

http://uic.sourceforge.net/images/designer-workflow.png

PanelVue1.java

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.border.*;
 
/** panel qui permet de saisir et afficher le rayon d'un cercle. (vue 1)
*/
 
public class PanelVue1 extends JPanel implements ActionListener {
 
	// modèle de données
	private Cercle modèle;
 
 	// objets graphiques
	JLabel jLabel = new JLabel("Rayon  ");
	JTextField jTextField = new JTextField(20);
 
	// constructeur
	public PanelVue1(Cercle modèle) {
 
		// enregistrement de cette vue auprès du modèle
		this.modèle = modèle;
		modèle.addActionListener(this);
 
		// construction du panel
		this.setBorder(new TitledBorder("1ère vue"));
		this.setLayout(new BorderLayout());
		this.add(jLabel, BorderLayout.WEST);
		this.add(jTextField, BorderLayout.CENTER);
		jTextField.setText("" + modèle.getRayon());
 
		// ajout du listener pour le textField.
		// si le jTextfield est modifié, le modèle doit l'être aussi.
		jTextField.addActionListener(new ActionListener() {
			public void actionPerformed(ActionEvent e) {
				modifierRayon();
			}
		});
 
	} // fin du constructeur
 
	// méthode appelée quand le rayon est modifié dans le modèle
	public void actionPerformed(ActionEvent e) {
			jTextField.setText("" + modèle.getRayon());
	}
 
	// lecture du textField et modification du rayon
	private void modifierRayon() {
		try { 
			int r = Integer.parseInt(jTextField.getText());
			if (r>100) throw new NumberFormatException();
			modèle.setRayon(r);
		}
		catch (NumberFormatException nfe) {
			jTextField.setText("erreur");
		}
	}
}

PanelVue2.java

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
28
29
30
31
32
33
34
35
36
37
38
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.border.*;
 
/** panel qui permet de dessiner un cercle (vue 2)
*/
 
public class PanelVue2 extends JPanel implements ActionListener {
 
	// modèle de données
	private Cercle modèle;
 
	// constructeur
	public PanelVue2(Cercle modèle) {
 
		// enregistrement de cette vue auprès du modèle
		this.modèle = modèle;
		modèle.addActionListener(this);
 
		this.setBorder(new TitledBorder("2ème vue"));
 
	} // fin du constructeur
 
	// méthode appelée quand le rayon est modifié dans le modèle
	public void actionPerformed(ActionEvent e) {
		this.repaint();
	}
 
	// méthode qui dessine le cercle en tenant compte du rayon du modèle
	public void paintComponent(Graphics g) {
		super.paintComponent(g); // permet d'effacer le dessin précédent
		int r = modèle.getRayon();
		int xCentre = this.getWidth() / 2;
		int yCentre = this.getHeight() / 2;
		g.drawOval(xCentre - r, yCentre - r , 2*r, 2*r);
	}
}

PanelVue3.java

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.event.*;
import javax.swing.border.*;
 
/** panel qui contient un slider (vue 3)
*/
 
public class PanelVue3 extends JPanel implements ActionListener {
 
	// modèle de données
	private Cercle modèle;
 
	// slider
	JSlider slider = new JSlider(0,100,0);
 
	// constructeur
	public PanelVue3(Cercle modèle) {
 
		// enregistrement de cette vue auprès du modèle
		this.modèle = modèle;
		modèle.addActionListener(this);
 
		// ajout du slider au panel
		slider.setMinorTickSpacing(5); 
		slider.setMajorTickSpacing(10); 
		slider.setPaintLabels(true);
		slider.setPaintTicks(true);
		slider.setValue(modèle.getRayon());
		this.setLayout(new BorderLayout());
		this.add(slider, BorderLayout.CENTER);
		this.setBorder(new TitledBorder("3ème vue"));
 
		// enregistrement du listener pour le slider
		slider.addChangeListener(new ChangeListener() {
			public void stateChanged(ChangeEvent e) {
				modifierRayon();
			}
		});
 
	} // fin du constructeur
 
	// méthode appelée quand le rayon est modifié dans le modèle
	public void actionPerformed(ActionEvent e) {
		slider.setValue(modèle.getRayon());
	}
 
	// modification du rayon dans le modèle en fonction de la valeur du slider
	private void modifierRayon() {
			int r = slider.getValue();
			modèle.setRayon(r);
	}
 
}

Etudie bien cet exemple, cela te fera certainement comprendre le concept MVC...

Moi, en tout cas, c'est avec ça que je l'ai (enfin) compris...
;-)

18/08/2005, 08h03
Gfx

Un bouquin indispensable et quelques articles sur les design patterns.
18/08/2005, 08h30
viena

Citation:

Envoyé par unNew

L'image que tu presentes (...) elle tend a vouloir signifier que le modele interagit avec la vue, ce qui n'en est rien, puisque le modele passe obligatoirement par le controleur.

Effectivement, pour envoyer quelque chose a la vue, le modele passe obligatoirement par le controleur. Cependant, c'est pas parce qu'il y passe qu'il ne peut pas envoyer quelque chose à la vue.
Typiquement, si tu as un écran qui demande de saisir un pseudo à une personne et un second ecran qui affiche le nom de la personne, c'est le modele qui ira recupérer le nom de la personne en base pour l'envoyer vers la vue via le controleur. Dans ce cas, le controleur n'est qu'un passage obligé, cependant, le resultat dans l'absolu est bien envoyé du modele. Les system.out.println représente bien la vue dans mon exemple, mais le resultat qu'ils affichent a bien été déduit par le modele. Il faut juste imaginer que dans le modele MVC, ce resultat transitera par le controleur. Ce dernier permettra, en autre, de définir le bon ecran (vue) à ouvrir par exemple.
18/08/2005, 15h32
stoukou

je veux savoir pour le modele m2vc pour les applications swing est ce que c'est le meme principe ou pas.
et est ce que avec le framework Spring on est obligé de passé par des "outils" comme Ibatis SqlMap pour qu'il soit applicable ou pas.
18/08/2005, 16h46
Glob

Heu... le modèle "envoie" des trucs?
Ca serait pas plutôt au contrôleur de connaître et d'interroger le modèle?

Pasque le modèle, en principe, il ne connaît ni le contrôleur ni la vue. Non? :roll:
18/08/2005, 20h22
Gfx

Si ton modèle émet des événements, comme les PropertyChangeEvent des JavaBeans, tu peux considérer qu'il envoie des infos sans pour autant vraiment connaître le contrôleur et/ou la vue.
19/08/2005, 09h19
viena

Citation:

Heu... le modèle "envoie" des trucs?
Ca serait pas plutôt au contrôleur de connaître et d'interroger le modèle?

Le modele ne connnait pas le controleur, c'est le controleur qui interroge le modele et le modele lui donne ce qu'il demande. Il lui envoie ce qu'il veut...
19/08/2005, 09h32
Glob

Citation:

Envoyé par viena

Citation:

Heu... le modèle "envoie" des trucs?
Ca serait pas plutôt au contrôleur de connaître et d'interroger le modèle?

Le modele ne connnait pas le controleur, c'est le controleur qui interroge le modele et le modele lui donne ce qu'il demande. Il lui envoie ce qu'il veut...

Ah très bien. J'avais peur, dans le cas où le contrôleur lance un thread sans attendre un résultat, que le modèle doive connaître le contrôleur pour lui envoyer des infos de son propre chef.
19/08/2005, 09h39
viena

non, n'ais pas peur :wink:
Le principe de la séparation des couche est un principe qui oblige les couche à ne communiquer qu'avec les couches immédiatement supérieures et inférieures à elle et à ne connaitre que la couche inférieure. Donc le modele ne communique qu'avec le controleur (et avec une autre couche inférieure si on en ajoute une pour mieux séparer : acces aux données par exemple...) et qui ne connait que cette meme couche inférieure si elle existe.
Donc le modele n'enverra rien au controleur sans une demande expres de la part de celui ci.
19/08/2005, 09h43
calogerogigante

OK pour le principe de la séparation des couches...

Mais est-ce toujours faisable ?

Non, je ne pense pas, à mon avis, car dans mon exemple, le controlleur est un peu disséminé dans les vues, non ?
Dites-moi si je me trompe ?

Par exemple, voir le dessin (schéma) ci-dessus trouvé sur un site quelque part...
19/08/2005, 09h51
Gfx

Disons que c'est pas toujours facile à faire :)
19/08/2005, 09h51
viena

Je ne veux pas m'avancer trop, je n'y connais absolument rien en Swing ou Awt. Cependant, dans la programmation objet, tu dois pouvoir séparer tes éléments pour isoler totalement les couches quelques soit ton type d'application. :roll:
19/08/2005, 09h59
calogerogigante

Citation:

Disons que c'est pas toujours facile à faire

C'est pour ça qu'au début, j'ai beaucoup galéré pour comprendre le principe du MVC.

On ne nous explique pas toujours que l'idée du "contrôle" est parfois (même souvent ) assez étroitement lié à la vue.

Mais au fond, c'est logique, car les composants de la vue sont les éléments qui permettent de contrôler l'action de l'utilisateur...

Le lien assez étroit qui existe entre Vue et Controller ne doit pas être mis sous silence, et c'est souvent le cas dans les tutoriels.

Par contre: je suis d'accord avec vous tous, quand vous dites que le modèle, lui, est TOTALEMENT indépendant de la vue et du contrôle.

Le modèle doit pouvoir exister et fonctionner sans les actions d'un utilisateur.

C'est le cas de l'exemple ci-dessus : je pourrais très bien enlever tous les listeners, et faire une programmation qui afficherait le cercle pendant 10 sec à son rayon maximum, puis pendant 15 sec à son rayon minimum...

Le modèle Cercle est ici idéalement ré-utilisable dans toutes les situations (en tous cas, il vaut mieux l'implémenter de la sorte, pour pouvoir le ré-utiliser...)
;-)
19/08/2005, 10h05
viena

Citation:

Le modèle Cercle est ici idéalement ré-utilisable dans toutes les situations (en tous cas, il vaut mieux l'implémenter de la sorte, pour pouvoir le ré-utiliser...)

Effectivement. Et il y a un autre aspect très important : la maintenabilité. Il est quand même beaucoup plus pratique de ne pas etre obligé de toucher au métier quand on modifie les ecrans... La séparation idéale des couche (j'ai bien dit idéal, un idéal difficile à atteindre...) une modification dans une couche n'impact pas les autres couches.
19/08/2005, 10h09
calogerogigante

C'est gai quand on se rend compte qu'on a bien compris la chose, qu'on peut la ré-expliquer, et que les autres personnes du forum (plus doués que moi en programmation) sont d'accord avec vos propos...
;-)
;-)
Je vais passer une bonne journée, je crois...

Voir 40 message(s) de cette discussion en une page