[WPF & MVVM] Mediator et GC

Version imprimable

Bonsoir à tous,

j'ai un petit soucis lors de l'utilisation d'un mediator.

J'ai une classe Plugin qui contient ceci :

Code:

1
2
3
4
5
6
7
8
public void Associate(String Identifiant, String Header, String Content)
        {
            Messenger.Instance.Register(Identifiant, delegate
            {
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + Header);
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + Content);
            });
        }

Et une classe loader qui contient :

Code:

1
2
3
4
5
6
7
8
public class Loader : Plugin
    {
        public Loader()
        {
            this.Namespace = "Cinema.Plugin";
            this.Associate("Add", "/Headers/HeaderAdd.xaml", "/Contents/Add.xaml");
        }
    }

Lorsque le message "Add" est emis, la méthode n'est pas appelé car il semblerait que l'objet ne soit plus en vie (qu'il ai été collecté alors qu'il ne l'est pas).

Maintenant, si je fait ceci à la place :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
public class Loader : Plugin
    {
        public Loader()
        {
            this.Namespace = "Cinema.Plugin";
            Messenger.Instance.Register(Identifiant, delegate
            {
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + "/Headers/HeaderAdd.xaml");
                Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + "/Contents/Add.xaml");
            });
        }
    }

Tout fonctionne à merveille, pouvez vous me dire quel est le problème lorsque que je met le Register dans la classe mère ?? (qui est dans une autre assembly, je sais pas si ça peut jouer).

Merci d'avance.

Cordialement,
NeoKript

J'ai peut-être une idée, mais sans garantie que c'est bien ça le problème...

La classe Messenger utilise le pattern WeakEvent, pour éviter les fuites mémoires. Cela signifie qu'il ne conserve pas de références fortes aux handlers des messages, mais seulement des WeakReference. Comme tu t'abonnes au message avec une méthode anonyme qui capture des variables locales, le compilateur crée (de façon "invisible" pour toi) un nouvel objet anonyme qui va contenir ces variables. Mais toi, tu passes juste le delegate à la méthode Register, et tu ne conserves pas de référence à l'objet anonyme. Il n'existe donc aucune référence à cet objet, et donc rien qui l'empêche d'être collecté.

(certes, ça n'explique pas pourquoi ça fonctionne dans le 2e cas...)

A priori, si tu utilisais une "vraie" méthode au lieu d'une méthode anonyme, ça devrait fonctionner. Mais vu que tu as besoin de capturer des variables locales, ça ne va pas être possible...

Une autre solution serait de garder une référence vers le delegate lui-même, pour éviter que l'objet ne soit collecté. Un truc dans ce style :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 Action _registeredAction; public void Associate(String Identifiant, String Header, String Content) { Action action = delegate { Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + Header); Messenger.Instance.Notify(MediatorMessages.MainWindows_SetContent, "pack://application:,,,/" + this.Namespace + ";component" + Content); } Messenger.Instance.Register(Identifiant, action); _registeredAction = action; }
Il faudrait peut-être plutôt faire ça avec une liste d'action, vu que je suppose que la méthode Associate sera appelée plusieurs fois...

Salut,

Et merci pour ta réponse.
En effet, le problème viens de là !

Je viens de tester ceci :
Code:

1 2 3 4 5 6 7 8 9 public void Associate(String Identifiant, String Header, String Content) { Messenger.Instance.Register(Identifiant, Param => this.SetContent()); } private void SetContent() { Messenger.Instance.Notify(MediatorMessages.MainWindows_SetHeader, "pack://application:,,,/" + this.Namespace + ";component" + "/Headers/HeaderAdd.xaml"); }
Et ça fonctionne parfaitement, mais dès qu'on fait passer une variable de la méthode, plus rien ...

Mais du coup, en effet je ne comprend pas pourquoi cela fonctionnait dans le second cas ...

Ton exemple fonctionne, du coup je vais stocké les Actions dans une List<>...

Par contre, si quelqu'un sait pourquoi ça fonctionnais quand c'était dans la même classe je suis preneur (à cause de la pile qui contenait encore les valeur... bizarre quand même)

Merci

10/01/2011, 23h22
tomlev

Citation:

Envoyé par NeoKript

(à cause de la pile qui contenait encore les valeur... bizarre quand même)

Ca pourrait être un truc comme ça...

Si tu veux une réponse d'expert, tu peux poser la question sur Stack Overflow (en anglais bien sûr). Il y a très souvent des grosses pointures qui viennent répondre aux questions (genre Eric Lippert, Jon Skeet...)
11/01/2011, 16h56
jmix90

Une idée en lisant le code :

Dans le deuxième exemple, tu ne passes pas le namespace comme une String mais via une référence "this" et cela doit maintenir en vie ton delegate car il contient une référence vers un objet encore en vie.

Dans le premier exemple, tu passes le namespace en tant que valeur (String) et le delegate n'est peut être pas maintenu en vie.

Si tu passes les paramètres en tant que reference(ref) peut être que cela fonctionnera ?

Bon courage !
11/01/2011, 17h15
tomlev

Citation:

Envoyé par jmix90

cela doit maintenir en vie ton delegate car il contient une référence vers un objet encore en vie.

Ben non... le fait d'avoir une référence vers un objet en vie n'empêche pas d'être collecté par le GC, c'est dans l'autre sens que ça se passe. Il faut qu'un objet en vie ait une référence vers le delegate pour l'empêcher d'être collecté
11/01/2011, 17h56
jmix90
Oui, mais il me semble que la méthode anonyme ne sera pas transformé de la même façon par le compilateur :
- Si elle utilise une variable du même scope(par exemple i dans une boucle for), une nouvelle classe sera créé dynamiquement par le compilateur avec notre méthode dessus. Cette instance utilisée pour être garbage collectée. C'est notre premier cas.
- Si elle utilise un field de la classe, comme dans notre deuxième cas, une méthode sera rajouté sur la classe par le compilateur... et sera donc toujours présente...
Qu'est ce que tu en penses ?

PS: c'est ce que je comprends de : http://www.codeproject.com/KB/cs/Ins...usMethods.aspx

Citation:

Envoyé par jmix90

Qu'est ce que tu en penses ?

Oui, il me semble que c'est ça.

Je viens de faire un petit test avec LINQPad :
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 void Main() { string s = "aaa"; // Capture une variable locale et appelle une méthode d'instance Action a1 = () => Foo(s); // Ne capture pas de variable locale et appelle une méthode d'instance Action a2 = () => Foo("bbb"); // Capture une variable locale et appelle une méthode statique Action a3 = () => Bar(s); // Ne capture pas de variable locale et appelle une méthode statique Action a4 = () => Bar("bbb"); Console.WriteLine ("a1: Declared in {0} - IsStatic = {1}", a1.Method.DeclaringType, a1.Method.IsStatic); Console.WriteLine ("a2: Declared in {0} - IsStatic = {1}", a2.Method.DeclaringType, a2.Method.IsStatic); Console.WriteLine ("a3: Declared in {0} - IsStatic = {1}", a3.Method.DeclaringType, a3.Method.IsStatic); Console.WriteLine ("a4: Declared in {0} - IsStatic = {1}", a4.Method.DeclaringType, a4.Method.IsStatic); } void Foo(string s) { Console.WriteLine(s); } static void Bar(string s) { Console.WriteLine(s); }
Ca me sort le résultat suivant :

Citation:

a1: Declared in UserQuery+<>c__DisplayClass5 - IsStatic = False
a2: Declared in UserQuery - IsStatic = False
a3: Declared in UserQuery+<>c__DisplayClass5 - IsStatic = False
a4: Declared in UserQuery - IsStatic = True

Donc en gros :

1. Dès qu'on capture une variable locale, ça crée une nouvelle classe (on remarque d'ailleurs que c'est la même pour les 2 fois où s est capturée). L'instance de cette classe sort du scope dès qu'on quitte la méthode, et peut donc être collectée.

2. Si on ne capture pas de variable locale mais qu'on fait référence à un membre d'instance, ça crée la méthode d'instance dans la classe courante. Le delegate reste donc vivant jusqu'à ce que l'instance courante soit collectée.

3. Si on ne capture pas de variable locale et qu'on ne fait pas référence à un membre d'instance, ça crée une méthode statique, donc il n'y a aucune instance à collecter

En regardant à nouveau le code de NeoKript, en fait c'est assez logique...
Dans le premier code, la méthode Associate capture le paramètre (assimilable à une variable locale) Identifiant, on se retrouve donc dans le cas 1. Par contre, en le faisant la même chose dans le constructeur de Loader, aucune variable locale n'est capturée, vu que Identifiant est un membre de la classe (je suppose). On se retrouve donc dans le cas 2.

11/01/2011, 19h50
jmix90

On est d'accord :-)
Deep dive in delegate world :P
12/01/2011, 07h52
jmix90

Mmh j'ai peut être parlé trop vite ...
Il faudrait vérifié que cette instance créée n'est pas référencé au niveau de la classe via un attribut auquel cas mon argument ne serait pas valide :-(

Sinon, si ce n'est pas ca, il faudrait voir au niveau du Mediator lui même ce qu'il se passe sur la weak référence.

++