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.