Discussion :

[alves.seb]

Voilà je travaille en ce moment sur le pattern mvvm.

En fonction de composant existant je suis en train de me recréer une petite librairie simple pour utiliser le Mvvm dans mes projets.

Actuellement j'ai implémenté/adapté :

- RelayCommand et RelayCommandGeneric (pouvant passer des paramètres)
- ViewModelbase : Passage par des arbres d’expression Linq en modifiant légèrement la signature de OnPropertyChanged. Possibilité de faire ce genre de chose :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 public String Title
        {
            get
            {
                return title;
            }
            set
            {
                title = value;
                OnPropertyChanged(() => Title);
            }
        }

- Attached Behavior : permettant actionner une commande WPF lorsqu’un évènement est déclenché. Possibilité de gérer une collection d'événement :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
//xaml
<JadeMvvm:EventCommander.Mappings>
        <JadeMvvm:CommandEvent Command="{Binding BehaviorClosedCommand}"
                           Event="Closed"/>
    </JadeMvvm:EventCommander.Mappings>
 
//Code View Model
public void ClosedCommand(EventParameters e)
        {
            MessageBox.Show("Closed Command");
        }

- Il me reste pour l'instant la notion de communication par message entre différente vue.

- Par contre si je veut respecter l'indépendance des vues entre elle comment faire si je veut par exemple afficher une vue à partir d'un viewmodel sans connaitre cette vue mais uniquement son viewmodel. En gros faire un show sur une autre vue à partir d'un viewmodel.

Dans la même idée: est-ce que dans un viewmodel faire un MessageBox.Show("Message") est correct d'un point du vue du pattern mvvm ?

Merci par avance pour vos réponse.

Seb.

[Thomas Lebrun]

Dans la même idée: est-ce que dans un viewmodel faire un MessageBox.Show("Message") est correct d'un point du vue du pattern mvvm ?

Non. A mon sens, les ViewModels doivent être le plus indépendant possibles donc si tu commences à insérer des boites de dialogue, tu "spécialises" ton VM.

[alves.seb]

C'est bien ce que je pensais aussi.

Ton post répond parfaitement à ce que je cherchais sur le sujet , je vais pouvoir m'en inspirer pour enrichir ma petite librairie MVVM.

Merci pour les infos.

Seb.

[tomlev]

- ViewModelbase : Passage par des arbres d’expression Linq en modifiant légèrement la signature de OnPropertyChanged. Possibilité de faire ce genre de chose :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 public String Title
        {
            get
            {
                return title;
            }
            set
            {
                title = value;
                OnPropertyChanged(() => Title);
            }
        }

J'utilise le même système, ça a le gros avantage d'être vérifié à la compilation et de supporter la refactorisation

- Par contre si je veut respecter l'indépendance des vues entre elle comment faire si je veut par exemple afficher une vue à partir d'un viewmodel sans connaitre cette vue mais uniquement son viewmodel. En gros faire un show sur une autre vue à partir d'un viewmodel.

Définis des DataTemplates pour chaque type de ViewModel, et afficher le ViewModel dans un ContentControl. WPF choisira automatiquement le template qui correspond au type du ViewModel.

Code XML :

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

1
2
3
4
5
6
<DataTemplate DataType="{x:Type vm:TotoViewModel}">
    <v:TotoView />
</DataTemplate>
<DataTemplate DataType="{x:Type vm:TitiViewModel}">
    <v:TitiView />
</DataTemplate>

[alves.seb]

Premièrement merci pour vos réponses.

Comme vous avez du le voir je me pose bcp de question sur ce pattern et je viens en faite de regarder rapidement : WPF Model-View-ViewModel Toolkit 0.1. sur codeplex.

Je m'aperçoit dans leur démo qu'il y a ce genre de chose dans le code behind associé au vue xaml :

Code :

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

1
2
3
4
5
6
 
 private void OnActivated(object sender, EventArgs e)
        {
            MainViewModel mainViewModel = DataContext as MainViewModel;
etc ...
}

En gros il gère des événements de façon classique et accède depuis la vue au viewmodel lui étant associé. C'est sur que dans ce cas cela simplifie l'implémentation de ce pattern.

Et qu'on on regarde le reste, il en n'est de même. Par exemple si on désire rafraichir un usercontrol à partir d'une view principal, bé ils s'embêtent pas en gros le viewmodel principal connait le viewmodel du usercontrol et appelle une méthode de rafraichissement.

Bref si quelqu'un à déjà regardé ce toolkit, que pensez-vous de cette façon de faire ? Quand je vois ça je me demande jusqu'à quel point doit-on avoir un couplage faible entre les vues sans que le projet devienne une usine à gaz à mettre en place.

Merci.

Seb

[tomlev]

J'ai utilisé des bouts de ce toolkit (notamment les classes DelegateCommand et CommandReference) mais j'ai pas trop regardé le code des exemples.

Perso j'aime pas trop cette façon de faire : à partir du moment où tu fais explicitement référence au ViewModel dans le code-behind, tu perds la séparation entre vue et modèle, tu introduis du couplage.

Je n'utilise quasiment jamais de code-behind, et quand je le fais, c'est pour implémenter des trucs strictement en rapport avec la vue, jamais avec le ViewModel. A mon avis c'est une condition sine qua non pour garder une architecture bien découplée avec une couche ViewModel complètement testable

[Yo Eight]

Je vois pas l'intérêt d'implémenter un système de message entre les vues. Il serait plus judicieux de faire un système de message entre les ViewModel. Il existe une implémentation du pattern Mediator qui est très puissant pour le MVVM que tu peux retrouver dans le MVVM Foundation

De plus, si tu as fait une bonne implémentation du MVVM tu ne devrais nulle part faire une instanciation de ViewModel dans une vue, car chaque ViewModel est associé à un DataTemplate qui reprendra la View que l'on voudra associer au ViewModel comme le montre tomlev. Le seul ViewModel qui doit être instancié est le MainViewModel.

Je l'instancie personnellement en faisant un handle de l'event OnStartup dans le App.xaml.cs. Je l'affecte dans le DataContext de ma MainFrame. Comme cela, mon MainFrame.xaml.cs reste totalement vierge.

[tomlev]

Je vois pas l'intérêt d'implémenter un système de message entre les vues. Il serait plus judicieux de faire un système de message entre les ViewModel. Il existe une implémentation du pattern Mediator qui est très puissant pour le MVVM que tu peux retrouver dans le MVVM Foundation

+1, j'avais même pas relevé... c'est effectivement entre les ViewModel et non entre les vues qu'il faut communiquer

De plus, si tu as fait une bonne implémentation du MVVM tu ne devrais nulle part faire une instanciation de ViewModel dans une vue, car chaque ViewModel est associé à un DataTemplate qui reprendra la View que l'on voudra associer au ViewModel comme le montre tomlev. Le seul ViewModel qui doit être instancié est le MainViewModel.

Je suis d'accord avec toi, mais MVVM ne définit pas de règles strictes, c'est plutôt des guidelines... tout le monde n'en a pas la même interprétation, et pas mal de gens (y compris des "gourous" de MVVM) préfèrent instancier le ViewModel dans la vue. Personnellement ça m'a toujours semblé bizarre...

En fait, je pense que ça dépend de si on voit le ViewModel comme une "vue du modèle" ou comme un "modèle de la vue", et je suis plutôt dans le 1er cas

[alves.seb]

Petite Question.

Pour info j'utilise les composants infragistics et notamment le composant permettant de docker mes onglet et fenêtre facilement.

Imaginons que j'ai ma fenêtre principal composé d'un menu et de ce qu'on va appeler un TabGroupPane dans le lequel je peut mettre des ContentPane à qui j'associerais mes usercontrol. Cela va me permettre en gros d'afficher des onglets à l'intérieur d'un container TabGroupPane que je pourrait déplacer/docker etc.... (1 Onglet = 1 UserControl)

Quand je clique sur une des icônes du menu j'aimerais pouvoir dynamiquement créer un onglet (donc ajouter une ContentPane au tabGroupPane) avec le usercontrol correspondant à l'intérieur.
Comment faire en respectant la méthodologie MVVM ?

Dois-je disposer dans mon ViewModel principale d'une collection de contentPane dans lequel je vais créer et associer mon usercontrol au déclenchement de la command associé au bouton du menu. Mais dans ce cas mon viewModel principale va se trimbaler une liste de contentpane qui est un composant graphique et en plus il faut que ce viewmodel fasse référence à d'autre viewmodel.

Bref quelqu'un aurait une idée sur la question ?

Merci d'avance.

[tomlev]

ben je suppose que le contrôle TabGroupPane en question a une propriété ItemsSource ? Et que chacun des ContentPane va afficher un ViewModel ? dans ce cas il suffit de binder l'ItemsSource à une collection de ViewModels

[alves.seb]

ben je suppose que le contrôle TabGroupPane en question a une propriété ItemsSource ? Et que chacun des ContentPane va afficher un ViewModel ? dans ce cas il suffit de binder l'ItemsSource à une collection de ViewModels

Je suppose que c'est grâce au DataTemplate que je vais pouvoir faire ça, comme tu l'a suggéré précédemment ?

Code :

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

1
2
3
4
 
<DataTemplate DataType="{x:Type vm:TotoViewModel}">
    <v:TotoView />
</DataTemplate>

[Yo Eight]

C'est plutôt au niveau du UserControl que tu feras le binding avec le ItemsSource et ton ViewModel. Le DataTemplate n'est là que pour déclarer le lien logique.

@ tomlev

Il est vrai que le MVVM n'est pas un ensemble d'obligations mais de recommandations . Je pousse peut-être trop loin, mais tant que c'est possible et que ce n'est pas "chiant", j'essaye d'éviter les instanciations explicites

[alves.seb]

Concernant le faite de pouvoir ouvrir une fenêtre détails à partir d'une fenêtre principal avec le pattern MVVM.

Est-ce que si on se débrouille à faire l'opération d'afficher la fenêtre détails dans le code-behind de la fenêtre principal vous choque ?
Sans avoir de référence avec le viewmodel on n'est d'accord. Pour cela je m'aiderais du pattern mediator, ainsi en implémentant une interface dans classe contenant le code-behind je serais averti qu'il faut lancer l'action d'ouvrir la fenêtre détails. Seul soucis ma classe contenant le code-behind doit connaitre la vue détails.

Je sais que dans le pattern MVVM on doit écrire le moins de chose possible dans le code-behind mais ça serait juste ici pour lancer une fenêtre ou un Messagebox par exemple.

Merci.