Discussion :

[Takumi]

Bonjour,

Je désire apprendre MVVM et pour cela je souhaite reprendre une application que j'avais commencé (mais pas finis, ce sera l'occasion j'éspère...) afin de la refondre en suivant cette architecture. J'ai donc lu pas mal de tuto, article de blog de différent développeurs et parfois des articles sur des techniques plus ou moins avancés qui ne me seront pas utiles pour le moment je pense, mais toujours bon à mettre de côté quand le moment viendra. J'ai donc de mon application repris toutes les classes que j'avais faite, le coeur même. Ces classes vont constituer mes models.

Cependant là ou je bloque le plus c'est sur les view et view-models.
Par exemple je n'arrive pas à voir comment faire la chose, j'ai compris le principe mais j'arrive pas à voir comment faire pour savoir qu'elle view-model créer. Si j'ai bien compris il me suffirait par exemple de découper mon application en différent petit UserControl qui chacun aurait son propre view-model?
Ensuite aussi en regardant ces deux articles:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

http://www.codeproject.com/KB/WPF/MVVMForDummies.aspx

Qui comporte un exemple de models assez similaire, une classe Person avec des attributs et méthodes classique à une classe Person. Je constate que leur utilisation dans les view-models est un peu différente.
Par exemple dans l'article de Josh Smith, il a une view-model pour une personne en particulier et dans cette view-model il reprend chaque attribut de la classe Person pour les exposer à la vue. Tandis que dans l'autre article, l'auteur n'a qu'un attribut de type Person dans son view-model et l'expose directement à la vue. A un moment, je crois que c'est dans ce même article de Josh Smith où il dit que l'architecture MVVM n'est pas un ensemble de règles bien précises mais plus une façon de faire, donc son implémentation peut diverger tant que le paradigme est respecté. Je pose tout de même ma question, des deux façon de faire précédentes laquelle est à préférer?

Un autre point sur lequel je bloque c'est le DataContext, j'ai regardé un peu les différents code source donné sur le web des applications MVVM, et parfois la façon de faire diverge aussi. Ce que je voudrais savoir c'est comment il faudrait résonner pour savoir comment mettre le view-model dans le DataContext de la view? Ma question est pas claire, moi même en la lisant je le trouve. Mais je bloque sur le DataContext et comment mettre la view-model dedans, mais j'arrive pas à exprimer exactement où je bloque et pourquoi. A force de réfléchir ça va surement se préciser.

Il y a d'autre point sur lequel je bloque un peu aussi, mais je les ai pas en tête sur le coup et si j'avais déjà à résoudre les précédents ça me ferait beaucoup avancer. Je suis désolé si je pose des questions de débutants, je débute avec cette architecture, j'ai l'impression de me retrouver quand je voulais apprendre MVC, que je ne comprenais rien à rien et que c'est au bout de 3 mois que je comprends.....

Je vous remercie d'avance pour votre aide

[Thomas Lebrun]

Pour savoir combien de VM je dois avoir, je me base sur les vues (Window/UserControls, etc.): j'ai 5 vues, alors je fais 5 VM, qui exposeront des propriétés qui seront bindées dans la vue.

[Takumi]

Bonsoir,

Merci pour ta réponse. Actuellement je bloque beaucoup sur la façon dont le DataContext des UserControl doit être remplis par les view-models. Après avoir vu plusieurs exemples et forum j'ai pu voir des choses différentes.

Par exemple si je prends le cas de l'article de Josh Smith, il remplis le DataContext de sa Window au démarrage avec la view-model approprié. Ensuite les UserControl se binde directement sur des propriété du DataContext de Window. Cela semble reprendre une phrase que j'ai vu souvent qui est de ne mettre aucune ligne dans le code behind des views.

Cependant j'ai vu aussi des exemples de code dans lequel les développeurs avaient assigné la view-model à une view depuis le code behind de cette dernière. Qu'est-ce qui est alors préférable de faire?

[pansoul]

Salut
Je suis un peu comme toi, en train d'apprendre le MVVM donc ma réponse est à prendre avec des pincettes.

Effectivement, j'ai l'impression qu'on peut définir le DataContext de 2 manières.

Dans le code behind de la vue ExempleView avec

Code :

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

1
2
 
this.DataContext = new ExempleModelView();

ou dans le XAML de la vue avec

Code :

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

1
2
 
DataContext="{Binding ExempleModelView, Source={MaSource}}">

La différence c'est qu'avec la version xaml, si l'un des champs binder est une variable que tu initialises à une certaine valeur (et non pas une valeur alimenté par une requête en base qui nécessite l'exécution du programme pour être alimenté) et que tu utilises visual 2010 , tu verras
cette valeur dans ton éditeur graphique de XAML ce qui est assez pratique lors du développement pour mieux comprendre ce que fait un usercontrol.

A part ça , une autre différence est, comme tu l'as dit , de ne pas avoir du tout de code behind dans la vue.

si tu veux un exemple (et que tu travailles sur VS2010) regarde ce tuto
MVVMLightToolkit par Nico-pyright page 6 l'auteur mentionne ce que je t'ai dit et tu supprime
la ligne

Code :

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

DataContext="{Binding HomeViewModelStatic, Source={StaticResource Locator}}"

dans Home.xaml et que tu mets dans Home.xaml.cs

Code :

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

this.DataContext = new HomeViewModel();

en oubliant pas de rajouter

Code :

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

using DemoMvvmLight.ViewModel;

Le programme fonctionne de la même manière mais quand tu travailles dans visual les champs concerné ne sont pas rempli comme la date par exemple.

[cinemania]

il n'y a pas de meilleur approche qu'une autre.

Parfois on peut, on on préfère intégrer le DataContext via le XAML, parfois on ne peut tout simplement pas dans le cas de ViewModels dépendants entre eux pour des scénarios complexes.

En fait, on peut faire du code-behind sans même violer les règles de MVVM.
Tout dépend de ce que l'on fait dans ce code behind, de sa complexité ...
Un designer qui a quelques bases peut très bien décider dans certains cas de faire un petit peu de code behind plutot que demander aux développeurs derrières de faire un "behaviors" ultra spécifique, super chiant à faire quand 5 lignes dans le code behind suffisent.

Personnellement j'ai tendance à préférer utiliser le code behind de ma window pour affecter les datacontext de mes usercontrols quand ils sont instanciés dès le démarrage, cela permet plus de libertés dans la conception de ton ViewModel. Mais là encore pas de méthode universelle.
En fait on peu dire que n'importe quel designer est quand meme capable de comprendre ou taper lui meme

Code :

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

this.DataContext = new MonViewModel();

Pour ton autre question, quand à savoir comment découper...
En fait fait d'abord toutes tes vues, pour voir à peut prêt comment ton interface sera.
Une fois que tu as toutes les vues, de là tu peut déduire le nombre de ViewModels car on a un viewmodel par vue.

Maintenant reste à voir le niveau de granularité que tu utilise pour définir une vue.
Une vue peut être considérée comme un composant simple, ou au contraire un UserControl regroupant nombre de controles et d'autres UserControls.
Mais là il n'y a pas de solution toute faite.
C'est à toi de décider comment tu compte procéder.
En général tu te rendra vite compte que ta granularité est mauvaise si tes ViewModels sont des usines à gaz et là il pourrait être nécessaire d'en ajouter sous des sous UserControls.

Après inutile de trop réfléchir aussi. Le problème avec les nouvelles approches qu'on ne maitrise pas, c'est qu'on ne veut tellement pas se planter que du coup on hésite à commencer, on ne sait pas trop par ou commencer, mais en fait il faut se jeter à l'eau, et au fur et à mesure des tutos corriger ce qui l'on à fait.
Si tu continue à vouloir comprendre sans pratiquer, tu continueras à te triturer les neurones pour rien et tu n'avancera pas.

[Takumi]

Bonsoir,

Merci pour ta réponse. Tu as entièrement raison, je passe plus de temps à réfléchir et me prendre la tête pour savoir comment faire ci ou comment faire ça sans réellement commencer quoi que ce soit. Au final, j'avance pas, m'embrouille et ça me frustre encore plus parce que j'ai l'impression d'encore moins bien comprendre à force. Faut que je fonce dans le tas, que je fasse des grosses erreurs, des erreurs immondes, abjectes mais au moins je les aurais fait et j'apprendrais. Mais n'étant pas habitué à cette architecture, ayant toujours fait mes programmes en C# de manière plus "traditionnelle" si on peut dire ça comme ça et ayant un programme qui commençait enfin à fonctionner, je me pose beaucoup de question sur comment je vais remettre ça en marche avec cette architecture, ou encore comment je doit refaire ça pour respecter le paradigme à la lettre (si possible). J'ai lu pas mal d'article et tuto sur MVVM à travers le web, et je remarque que très souvent les questions que je me pose n'ont jamais aucune réponse dans lesdits tuto et article, ou alors la réponse est très très dur à trouver. Mais ta réponse m'a fait un peu réfléchir et faut que je me jette à l'eau comme tu dit

Sinon pour revenir sur mes doutes concernant la manière dont je devais associer mon view-model à ma view. J'ai chercher un peu avec google et je suis tombé sur un exemple interessant pour binder une view-model depuis le xaml. Ca donne à peu près ça dans mon application:

Dans app.xaml:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
<Application x:Class="PlayerOne.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:vm="clr-namespace:PlayerOne.ViewModels"
             StartupUri="MainWindow.xaml">
    <Application.Resources>
        <vm:MainWindowViewModel x:Key="MainWindowViewModel" />
    </Application.Resources>
</Application>

Dans MainWindow.xaml :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<Window x:Class="PlayerOne.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="570" Width="1000" DataContext="{StaticResource MainWindowViewModel}">
    <Window.Resources>
        <ResourceDictionary Source="MainWindowResources.xaml" />
    </Window.Resources>
 
    <Grid>
        // Le reste du code....
    </Grid>
</Window>

J'ai eu juste à déclarer une view-model dans mon application puis binder le DataContext de ma Window dessus. Et ça marche nickel. Mais maintenant ce que je voudrais faire et essais (et ça semble pour le moment pas trop mal marcher), c'est tout binder par rapport au DataContext de la Window (qui contient la view-model de la Window) comme si c'était la racine. Par exemple la view-model de ma Window à une propriété de type AllPlaylistViewModel (c'est une application audio avec des playlist, des chansons, mais pas le café.....pas encore.......), c'est une view-model qui me permet d'afficher la liste des playlist et d'en sélectionner une pour afficher le contenu. Et justement dans cette view-model j'ai une propriété de type PlaylistDétailViewModel, qui renvois une view-model correspondant à la playlist selectionné, et cette méthode sera bindé depuis un autre UserControl qui se chargera d'afficher le contenu de la playlist. Et ainsi de suite avec le reste de mon application. Je sais pas si j'ai été très clair dans mes explications. En tout cas je l'espère.

[Takumi]

Bonjour,

Après avoir un peut continué mon application est tenté de respecter au mieux l'architecture MVVM, je me pose quelque question sur la façon dont je voulais faire les choses et si cela respecte toujours le paradigme.

Pour résumer mon idée, j'ai un view-model pour ma Window, c'est un peu comme un view-model parent / racine. A partir de là j'ai un premier UserControl qui contient une liste de playlist. Ce que je pensais faire c'était donc avoir ma list de playlist comme une propriété de la view-model de la Window, et le UserControl n'avait plus qu'a ce binder dessus.

Donc déjà à partir de là notre UserControl a son propre view-model lui aussi. Ensuite ce view-model est capable d'indiquer la playlist actuellement sélectionné. Maintenant j'ai un deuxième UserControl qui lui est capable justement d'afficher la liste complète des chansons contenus dans la playlist qui est actuellement sélectionné dans le premier UserControl. Donc le view-model de mon premier UserControl expose une propriété qui renvois un view-model pour la playlist actuellement sélectionné sur laquelle le deuxième UserControl va se binder.

Ensuite on aura à peu près le même scénario entre on deuxième UserControl et un troisième. Cette fois cela concerne la chanson qui est actuellement joué.

Tout cela c'était un peu pour situer le contexte. Maintenant ce que j'ai fait (et me pose beaucoup de questions dessus), c'est que par exemple pour la liste de Playlist, la propriété sur laquelle le view-model va se binder pour afficher la liste renvois une List<Playlist>. Ce qui veut dire que je manipule dans ma vue directement une des classes que j'ai dans mes models. Ce que je me demande c'est si je n'aurais pas déjà du directement créer chaque view-model pour chaque playlist, puis renvoyé une List<ViewModelPlaylist> ? Pour être plus générale est-ce que ma vue ne doit en aucun cas ne manipuler de model? Je pense avoir la réponse, ou une partie. Mais je voudrais avoir votre avis, savoir ce que j'ai mal fait ou où j'ai mal résonné.

Je vous remercie grandement pour votre aide.

[davcha]

En fait, tout dépend si tu as besoin ou non d'informations (propriétés, méthodes) supplémentaires dans tes ViewModels.

Par exemple, tes Playlist :

On peut imaginer que dans ta vue, tu as besoin de savoir si une Playlist a été ou non sélectionnée.
Ce genre d'information n'a vraiment rien à faire dans ta Playlist. Elle est davantage du ressort de ton ViewModelPlaylist.

Dans ce cas, ton ViewModelPlaylist encapsule ta Playlist, et tu manipules ta Playlist en passant par ton ViewModelPlaylist (puisque ta Playlist est privée, de toute façon).
Tout ça, pour ajouter une propriété "IsSelected".

Si t'as pas besoin de propriétés/méthodes supplémentaires, à priori tu peux t'en passer.

[Takumi]

Bonjour,

Merci pour ta réponse. J'avance un peu plus (quoi que lentement à cause de multiple hésitations et de prise de tête avant d'écrire une ligne de code) chaque jours dans mon application. Et la question que je posais qui est de savoir si par exemple il faut lier directement la vue au model se pose encore plus à moi en ce moment.

En faite j'ai dans mon application une vue qui affiche la liste complète des chansons présentes dans la playlist actuellement sélectionné. Pour le moment j'ai pas encore fait grand chose avec alors j'ai juste directement bindé une ObservableCollection<Song> (song est la classe qui contient une seule chanson avec ces propriétés: path, titre, durée,.....). Mais je sais que plus tard dans mon application j'aurais une vue qui va devoir reprendre les informations plus ou moins complètes de la chanson qui est actuellement en cours de lecture. Je n'aurais rien de très particulier à faire avec, il s'agira de ré-afficher les infos que l'instance contiendras. Donc je devrais surement faire un view-model qui sera associé à cette vue. Et ce que je me demande finalement c'est est-ce que dans chaque view-model de mes playlist je doit exposer une ObservableCollection<SongViewModel> pour afficher les chansons? Et après binder directement ma vue sur le selectedItem de ma liste de chanson. Ou bien créer à chaque fois à la volé un nouveau view-model à chaque fois que la chanson va changer? Et donc simplement laisser une ObservableCollection<Song> sur lequel la vue va se binder. Je me dit que ma première proposition peut être pas mal à mettre en place, notamment parce que je ne lie pas mes models directement sur la vue, mais par contre en terme de performance, devoir créer des collections de view-model pour chaque chanson, si le type a des playlist énormes......

Je suis désolé si je pose des questions un peu bizarres, mais je débute encore avec MVVM alors quand on se retrouve face à un choix mais qu'on a envie de suivre correctement le truc c'est pas facile de trancher sur "qu'est ce que je fait?".

[Pragmateek]

La deuxième solution me semble la bonne :
ton player utiliserait une ObservableCollection<Song> avec Song qui implémenterait INotifyPropertyChanged.

En effet, tu n'as pas nécessairement besoin d'un SongViewModel, ailleurs que dans l'interface SongView.

Un ViewModel est spécifique à une Vue, pas à une entité métier.

[cinemania]

je rejoint seriousme, effectivement, si tu tiens vraiment à respecter MVVM il est indispensable de bien séparer objets métiers donc Model et ViewModel...
par conséquent une ObservableCollection<SongViewModel> est une "hérésie".

non il vaut mieux des ObservableCollection<Song>
oublie pas que la vue par défaut que le composant qui est bindé sur la collection obtient, tu peux l'obtenir et de fait "filtrer" les éléments qu'il voit et affiche...
en effet, lors du databinding sur des collection, il faut savoir qu'en réalité, il va non pas garder la collection, mais une vue par défaut sur celle-ci.

Par chance les ObservableCollection ont des ICollectionView attachées, tu peux donc obtenir cette vue qui est utilisée par le databinding et tu peux donc faire ce que bon te semble comme récupérer l'élément courant sélectionné par l'utilisateur dans le composant bindé, ou intéragir sur la liste affichée en utilisant le filtrage pour réduire les membres affichées en fonction de critères donnés.

[Arsenic68]

Bonjour, je suis aussi débutant en MVVM, j'ai suivi le tutoriel de Jérémy Alles et lui utilise des ObservableCollection<ObjetViewModel>. Idem pour celui de Josh Smith.

D'où ma question, en quoi c'est mieux et comment faire le viewModel suivant votre vision?

[Thomas Lebrun]

D'où ma question, en quoi c'est mieux

Cela va te permettre:
- de simplifier la mise en place des tests unitaires
- de séparer le code du design
- d'apprendre un nouveau pattern dont tu tomberas vite amoureux

[Arsenic68]

Mvvm c'est bon, je l'épouse demain. Mais je parlais utiliser des ObservableCollection<Object> ou des ObservableCollection<ObjectViewModel>

[Pragmateek]

Si la question est "qu'est-ce qui est le mieux entre ObservableCollection<SongViewModel> et ObservableCollection<Song> ?" :
personnellement je délègue la création des ViewModel à chacune des sous-vues de l'application.
Ainsi la MainView recevra un ObservableCollection<Song> et en fera ce qu'elle veut, c'est à elle de gérer le rendu des Song (ou de le déléguer).
L'intérêt est le découplage des responsabilités entre les vues, l'inconvénient est que les ViewModels peuvent être moins évidents à localiser.

Alors qu'en centralisant la définition des ViewModels il est plus évident de les modifier en bloc si une nouvelle donnée est disponible, mais alors l'application est plus rigide car c'est au plus haut niveau qu'est "décidé" la structure des sous-vues.

[davcha]

Comment tu fais tes tests unitaires, seriousme ?

[Arsenic68]

Oui c'est bien ça la question, mais j'avoue ne pas plus comprendre

[Pragmateek]

Comment tu fais tes tests unitaires, seriousme ?

Pour être tout à fait honnête je privilégie la conception sur la testabilité.

Mais ce que je décris change peu de chose au processus de test unitaire puisque les ViewModels existent et restent accessibles, même s'ils ont besoin des Views.
Cependant ces Views ne sont pas le seul point d'entrée vers les ViewModels car j'utilise toujours des commandes et des bindings, ce qui permet de simuler les interactions utilisateurs.

Oui c'est bien ça la question, mais j'avoue ne pas plus comprendre

Au final je me retrouve avec une arborescence de View et ViewModel :
la MainView dispose d'un MainViewModel qui contient toutes les données que va manipuler l'application.
Puis cette MainView peut utiliser 0 ou n sous-views pour effectuer le rendu des données : si elle en utilise 0 elle ne créera pas de ViewModel, se contentant de rendre directement les données de son propre ViewModel;
si, au contraire, elle délègue à des sous-views, elle créera selon ses besoins des ViewModels : SubView1ViewModel, SubView2ViewModel... et les sous-views pourront elles-mêmes splitter leurs ViewModels si elles redélèguent.

J'avoue ne pas être trop sûr de la nature de ce pattern : MVVM, MVVM-like ou autre...

[davcha]

Arsenic68, dis-toi que ces "bonnes pratiques" ne sont pas là pour faire joli. Elles sont avant tout des solutions à des problèmes.

Dans le cas de ObservableCollection<Object> ou ObservableCollection<ObjectViewModel>, de la façon dont tu lies tes viewmodels à tes vues, etc... Tu peux trouver par toi-même les réponses qui conviendront à ton projet.

Si tu veux faire des tests unitaires de façon automatique, il faut permettre à ton code de fonctionner sans les vues.
A partir de là, donner la responsabilité d'instancier les viewmodels aux vues me parait être une très mauvaise idée.

[Pragmateek]

A partir de là, donner la responsabilité d'instancier les viewmodels aux vues me parait être une très mauvaise idée.

Une entité dite "View" a en fait deux rôles dans le pattern que j'ai décrit :
- "View" à proprement parler quand elle rend elle-même les informations de son "ViewModel",
- "Model" quand elle délègue à d'autres Views le rendu visuel d'autres informations.

Pour moi un ViewModel est un contrat entre une entité (une vue entre autre) et des vues à qui la première délègue la responsabilité de rendre des entités métiers.

Il est possible que j'utilise le terme "MVVM" abusivement pour ce pattern.