Discussion :

[leSeb]

Bonjour,

D'après ce que l'on peut lire sur le WPF, un des intérêts serait de séparer l'interface du code de l'application (MVVM - Model-Vue-VueModel). D'après ce schéma :
la Vue connait sa VueModel (l'inverse n'est pas vrai)
la VueModel connait son Model (l'inverse n'est pas vrai)

En ce qui concerne le lien entre les données et l'interface, il est réalisé par le principe de Binding qui :
- assure l'affichage des données de la VM dans l'interface
- répercute les modifications utilisateurs pour les placer dans la VM (pas de code behind).

Pour les actions, opération d'enregistrement par exemple, il faut passer par des ICommand qui fait le lien entre un bouton d'interface et la méthode de la VM.

Mais dans ce modèle où et comment gérer les exceptions liées à cette opération ?
Par exemple, lors de mon enregistrement, ma base de données n'est pas accessible, et ma méthode me retourne une Exception.
Comment informer l'utilisateur de cette erreur en respectant le MVVM ?

Merci d'avance.

[Invité]

Question interessante.

J'avais eu ce problème.

Je l'ai résolu comme suit.
Dans ma ViewModelBase, il y a une proprieté CriticalError. Cette proprieté est héritée par toutes ViewModel (ces derniières dérivent de ViewModelBase donc c'est logique).
Dans mes ViewModels, toutes erreurs engendrées me renseignent la proprieté CriticalError.
Dans ma vue, je vais binder la propriété Text d'un TextBox à ma propriété CriticalError.

C'est le seul moyen qui m'a permis de résoudre le problème.

[Thomas Lebrun]

Personnellement, je passe plutot par une interface (IActions) qui définit une méthode ShowMessage.

Ensuite, je dis que chacune de mes vues implémente cette interface. Puis, au moment d'instancier le ViewModel, je passe en paramètre l'instance de la classe qui implémente l'interface (autrement dit this).

Coté ViewModel, j'ai le constructeur qui prend en paramètre un objet du type IActions. J'initiale un membre de la classe du ViewModel avec la valeur récupérée et ensuite, dans le code, j'appelle juste la méthode Show.

Certes, cette technique nécessite d'écrire du code behind mais:
- celui-ci peut facilement être testé
- le principe du MVVM, ce n'est pas de ne pas écrire de code dans le code behind mais d'en écrire le moins possible !

[Invité]

Certes, cette technique nécessite d'écrire du code behind mais:
- celui-ci peut facilement être testé
- le principe du MVVM, ce n'est pas de ne pas écrire de code dans le code behind mais d'en écrire le moins possible !

Je suis d'accords avec toi.

Mais elle oblige la View et la ViewModel à se connaitre mutuellement ce qui n'est pas admissible non ?.

la Vue connait sa VueModel (l'inverse n'est pas vrai)

[ikeas]

oui justement ca me paraissait pas très cohérent que la vue connaisse les vuemodel ....

[leSeb]

oui justement ca me paraissait pas très cohérent que la vue connaisse les vuemodel ....

C'est tout à fait cohérent. L'objectif est que le moteur de l'application ne doit pas dépendre de l'interface (donc ne la connait pas).
Le moteur propose des fonctionnalités (données, actions, ...) par le biais de propriétés et de méthodes et l'interface ne fait que les utiliser : pour cela, elle doit connaitre le ViewModel.

Je pense qu'il y a moyen de faire un mixte de vos (thomas et h2s84) deux solutions pour respecter le modele MVVM.

- Créer une propriété CriticalError dans les classes de ViewModel.
- L'interface surveille la propriété CriticalError de sa ViewModel et affiche le message dès que sa valeur est modifiée (un peu de code behind mais pas trop).

Dans ce cas, le ViewModel ne connait pas la View. Mais c'est bien la View qui détermine l'affichage du message d'erreur.

Qu'en pensez-vous ?

[Thomas Lebrun]

Mais elle oblige la View et la ViewModel à se connaitre mutuellement ce qui n'est pas admissible non ?.

La Vue connait sa VueModel (l'inverse n'est pas vrai) par le DataContext mais le ViewModel ne connait pas la vue, il connait une instance de l'interface (implémentée par la vue). Donc, pour moi, ca roule...

[Jérem22]

Je suis OK avec Thomas: si les classes ViewModel reçoivent une interface implémenté par la vue, on ne "casse" pas le principe MVVM (sans interface en revanche on introduirait un couplage trop important).

Personnellement, ça m'arrive également de faire l'inverse. Par exemple si une classe ViewModel demande à ce que la vue associé soit fermée, je généralise ce concept avec une interface IRequestCloseViewModel (qui contient un event RequestClose). Cela permet de m'assurer un gestion cohérente de ce mécanisme à travers toutes les classes ViewModel.

Pour aller plus loin, tu peux regarder par ici (l'article est en plusieurs parties). L'auteur a conçu tout un framework MVVM qui contient de nombreux services utilisables pour afficher des messages, communiquer entre les classes MVVM tout en restant fidèle à la méthodologie.