Discussion :

[uluquiorra]

Bonsoir, depuis qu'on a attaqué notre nouvelle appli Wpf avec MVVM, j'ouvre mes vues de la manière suivante :

Code c# :

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

1
2
MonViewModel mvm = new MonViewModel(...);
mvm.ShowDialog();

Dans ma vue principale, j'ai plusieurs endroits où j'ouvre d'autres viewModel (à partir de diverses ICommand) :

Code c# :

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

1
2
3
4
5
6
7
MonSousViewModel1 msvm1 = new MonSousViewModel1(...);
mvm1.ShowDialog();
 
MonSousViewModel2 msvm1 = new MonSousViewModel2(...);
mvm2.ShowDialog();
 
...

Je savais dès le début qu'en fermant la vue (view.Close ou view.DialogResult = ...), son viewModel restait instancié et qu'on avait donc un peu de pseudo de perte mémoire.

Maintenant, je souhaite faire rentrer ça dans l'ordre, car si j'ouvre puis ferme 10 fois une sous vue, l'appli fait 10 fois 2Mo de plus dans la ram et j'ai autant de SousViewModel qui restent instanciés pour rien .

Donc, j'me suis dis, oki , on va juste mettre des références dans ma vue principale sur chaque sousViewModel et de les construire que pour leur première utilisation mais :

1 : ça fait carrément augmenter la mémoire utilisée par le processus.
2 : quand je fait un showDialog une seconde fois, ça explose en me disant grosso modo qu'il y a plus de xaml rattaché :
"
Impossible de définir Visibility ou d'appeler Show, ShowDialog ou WindowInteropHelper.EnsureHandle après la fermeture d'un objet Window.
"

Un petit conseil pour les bonnes pratiques à adopter serait le bien venu.
Merci d'avance.

[nova-id]

Salut, Il ne faut pas oublier le but du M-V-VM :
A la base, c'est un pattern MVC mais comme on voulait aussi bénéficier du binding bi-directionnel sans violer le contrôleur, celui-ci est devenu le VM.

Dans une application MVC, on s'adresse au contrôleur, qui déclenche l'ouverture de la vue. Dans une application M-V-VM, cela donne une méthode Show() dans la classe de VM. Celle-ci ouvre la vue (xaml) et récupère les données (en version basique).

Je te recommande d'ailleurs, de créer une classe de base abstraite et templatée pour gérer les VM. De cette manière, tu pourras factoriser et automatiser beaucoup de code.

Cdlt,

Cédric

[uluquiorra]

Je te recommande d'ailleurs, de créer une classe de base abstraite et templatée pour gérer les VM. De cette manière, tu pourras factoriser et automatiser beaucoup de code.

Bonsoir, si je comprend bien l'idée c'est d'avoir une classe de base permettant de manager tous les ViewModel (instanciés) de l'application :
Quelque-chose de ce genre :
http://www.codeproject.com/Articles/...e-MVVM-Pattern
?

[uluquiorra]

Bonjour, je viens d'intégrer le contenu de la solution proposée dans le post du lien ci-dessus.
Ben ça marche super bien, on a la main sur chaque instanciation des "models/viewModel/vues", et donc plus de perte de mémoire avec des view et des viewmodel se baladant dans la nature en attendant qu'un petit coup de GC.Collect fasse le ménage.

Mais bon y'a un soucis (ou une incompréhension de ma part), dans la méthode qui fait le showdialog (DialogService -> ligne 260), on affecte le viewModel de notre choix au dataContext de la vue nouvellement créée.
Et là dans le ViewModel, je ne sais pas comment récupérer un "événement/commande/message" qui me dise :
"ayé la vue vient d'être affectée, tu peux initialiser les truc qui doivent être initialisé après et seulement après que la vue ne soit plus à null."

Vous avez une idée ?



edit :
Autre question : j'ajoute souvent des event dans les constructeurs de mes ViewModel après l'affectation de la vue au DataContext en faisant un truc du genre : this.View.composantBidule.click += ...
Du coup c'est ça qui me gène mais bon en faisant ça je respecte probablement plus le concept MVVM ???

Merci d'avance pour vos conseils.