Discussion :

[Pilloutou]

Bonjour,

afin de séparer mon interface graphique de mon modèle, j'ai implémenté dans une classe de mon modèle un évenement de changement de valeur.

Solution1:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
public class Data {
 
   private double[] m_Data;     // ensemble de données lue
   private double m_LastData; // mémorise la dernière valeur lue
   public double LastData{
       get { return m_LastData;}
       private set {
             if (m_LastData != value) {
                       m_LastData = value;
                       LastValueChanged(this,new EventArgs());
             }
   }
 
   private AcquireData m_Acquire;
 
   public Data() {
        m_Data = new double[1000];
        m_Acquire = new AcquireData();
        m_Acquire.ReadValue += ChangeData;
   }
 
   // Fonction appelé lorsque l'évenement de mise à jour des données
   // est envoyé par l'objet m_Acquire
   public void ChangeData(object sender, eventargs ev) {
 
           Array.Copy(m_Acquire.DataRead, m_Data, value.Length);
 
           // Mise à jour de la dernière valeur
           // L'évenement est automatiquement déclenché
           LastData = m_Data[m_Data.Length-1];                      
   }
 
   pubilc event LastValueChangedEventHandler LastValueChanged;
 
   public delegate void LastValueChangedEventHandler(object sender,
 EventArgs e);
 
}

Lorsque la valeur change, l'évenement est appelé dans la propriété LastData.
La propriété LastData est spécialement crée pour cet évenement.

Solution 2:
Ou alors je crée une classe LastDataChangedEventArgs:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public class LastDataChangedEventArgs {
   private double m_Value;
   public double Value {
      get { return m_Value;}
   }
 
   public LastDataChangedEventArgs (double lastValue) {
       m_Value = lastValue;
   }
}

ce qui donnerait dans la méthode ChangeData:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
   // Fonction appelé lorsque l'évenement de mise à jour des données
   // est envoyé par l'objet m_Acquire
   public void ChangeData(object sender, eventargs ev) {
 
           Array.Copy(m_Acquire.DataRead, m_Data, value.Length);
 
           // Mise à jour de la dernière valeur
           // L'évenement est automatiquement déclenché
           LastValueChanged(this,new LastDataChangedEventArgs(m_Data
[m_Data.Length-1]));           
   }

Selon vous qu'est-ce qui est plus propre ?
La solution 1 ou la solution 2 ?
En fait, je me demande si je dois créee un évenement dans lequel je mets en argument la valeur ou si je crée une propriété LastValue qui déclenche l'évenement quand la valeur est réllement modifiée.

Merci pour vos conseils.

[dev01]

Salut .

les deux solutions sont possibles, après il faut savoir si ta propriété de la solution 1 ne va planter ton code si elle est utilisé dans une autre situation que la réponse à l'evènement.
De plus avec ta solution 1 il faut avoir l'objet dans la classe de gestion de l'évènement ce qui n'est pas toujours le cas.

En conclusion, je préfère la solution 2 mais les deux fonctionnent.

[Mehdi Feki]

Salut,

Sinon tu peux utiliser le pattern Observer

[Pilloutou]

Autre question toujours en rapport avec les évenements:
Supposons que je développe une application en suivant le design pattern mvc.

Faut-il définir la méthode associé à un evenement en même temps que le contrôle lui-même ou faut-il déclarer cette méthode dans la classe Controller ?

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class View:Form{
       public View() {
        TextBox txtBox=new TextBox();
         txtBox.Validated += controller.ValidateTxtBox;
       }
}
 
public class Controller {
 
       public void ValidateTxtBox(object sender, EventArgs e){...}    
}

ou faut-il ?

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
 
public class View:Form{
       public View() {
        TextBox txtBox=new TextBox();
        Controller controller = new Controller(this)
       }
}
 
public class Controller {
      View vue;
 
      public Controller(View vue) {
      this.vue=vue;
      txtBox.Validated += ValidateTxtBox;
}
       public void ValidateTxtBox(object sender, EventArgs e){...}    
}

Et sinon comment architecturez-vous vos applis windows ?

Merci

[Mehdi Feki]

Pour la deuxieme solution, le MVC n'a aucun interet si le controller accede à la vue et la vue accede au Controller, donc je pense que c'est à rejeter.

Tu peux utiliser la premiere, mais le probleme est que la view dans ce cas est dependante de la technologie du controller, l'interet de MVC est que la vue doit pouvoir etre implementé independament de la technologie du Controller.

De mon coté, on m'a toujours appris à utiliser le pattern Observer avec MVC, pour que le controller puisse suivre les evenements de la vue.

[Pilloutou]

Oui en fait pour la deuxième solution,

je devrais plutôt faire:

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
public class Main {
 
    public Main() {
         View vue = new View();
         Controller controller = new Controller(vue);
    }
}
 
public class View:Form{
       public View() {
        TextBox txtBox=new TextBox();
       }
}
 
public class Controller {
      View vue;
 
      public Controller(View vue) {
      this.vue=vue;
      txtBox.Validated += ValidateTxtBox;
}
       public void ValidateTxtBox(object sender, EventArgs e){...}    
}

Mais je me demande si ça a tellement un interêt de séparer la vue du contrôleur. Le plus important est de bien séparer le modèle mais d'après ce que j'ai vu il est très fréquent que dans une application riche, le contrôleur et la vue ne fasse qu'un.

[Mehdi Feki]

Mais je me demande si ça a tellement un interêt de séparer la vue du contrôleur. Le plus important est de bien séparer le modèle mais d'après ce que j'ai vu il est très fréquent que dans une application riche, le contrôleur et la vue ne fasse qu'un.

Suppose que un jour tu, veux refaire la meme application en ASP.Net, et que la vue et le controlleur sont liés. il faudra dans ce cas refaire tout le boulot.

Voila l'interet de la separation !!

En fait as-tu refléchit sur ma demande d'utilisation du pattern Observer ? Ou est-ce que la proposition ne t'a pa plu ?

Je n'ai recu aucun Feedback.

[Pilloutou]

Suppose que un jour tu, veux refaire la meme application en ASP.Net, et que la vue et le controlleur sont liés. il faudra dans ce cas refaire tout le boulot.

Ouais carrément juste.
Faut que je revois ça.

En fait as-tu refléchit sur ma demande d'utilisation du pattern Observer ? Ou est-ce que la proposition ne t'a pa plu ?

Si bien sûr, je cherche à l'implémenter. Je suis allé sur le site Web de Microsoft, mais tous leur exemple qui sont au format image sont manquants.
Je me suis rendu sur le lien que tu m'as proposé. C'est très interessant.
Mais comment fais-tu dans le cas où certaines modifications n'interessent pas tous les abonnés ? Oui supposons pour reprendre l'exemple du lien que tu m'as donné, que tous les investisseurs d'IBM ne soient pas interessé par la modification du prix ?

Merci.

[Mehdi Feki]

Investor s = new Investor("Sorros");
Investor b = new Investor("Berkshire");

// Create IBM stock and attach investors
IBM ibm = new IBM("IBM", 120.00);
ibm.Attach(s);
ibm.Attach(b);

Bein ici les deux investisseurs Sorros et Berkshire s'abonnent avec ce qui est en gras, donc c'est normal qu'il recoivent les notifications.

[Pilloutou]

En fait ce que je voulais dire, c'est que supposons que dans la classe stock, il y ait en plus une propriété quantité, comment préciser que l'investisseur Sorros soit interessé par l'évenement de modification de prix et que l'investisseur soit interessé par l'évenement de modification de quantité ?

Merci.

[Mehdi Feki]

Ah oui t'as raison,
normalement le pattern notifie les abonnés quand son état change. L'abonnement se fait par rapport à l'objet non pas par rapport à ses état.

Tu peux comme meme modifier le pattern en y ajoutant plusieurs Arraylist pour chaque membre de la classe Observable, mais je ne trouve pas que c'est une tres bonne idee, surtout si le structure de la classe va changer un un genre alors il faudre reimplementer de nouvelles methodes pour les nouveaux membre.

Je parlais de Observer, parce que je l'utilisait avec java, ce pattern est si connu qu'il a été implementé dans le SDK (Framework) Java ;Java Developer's Reference Using Observers . Et par suite le MVC sous java est tres facil à utiliser. J'ai fait une petite recherche pour voir de ce qui en est du coté Dot Net et je suis tombé sur ces deux liens:
Model View Controller (MVC) Using C#, Delegates and Events in .NET
Exploring the Observer Design Pattern

Et c'est les delegates qui sont utilisé pour implementer le pattern. En esperant qu'il soit pris en charge directement dans le Framework 3.0 ( mais j'en doute fort )

[etiennegaloup]

En fait c'est ce qu'il a fait.
Les evenements en .NET sont des delegates.

++

[Pilloutou]

Par contre, je viens de tester quelque chose d'assez sympa, le BindingSource. Je n'avais jamais trop essayé, mais c'est vraiment pas mal. Par contre, j'ai quelques p'tits soucis... A voir.