Votre ViewModel doit-il exposer les éléments XAML en tant que propriétés ou non?

Question

Fini la question StackOverflow Comment utiliser les convertisseurs WPF dans un modèle MVVM? : nous avons appris que les convertisseurs de valeur ne devaient pas être utilisés dans le modèle MVVM, car la fonctionnalité d'un convertisseur de valeur devait être gérée par le gestionnaire. ViewModel lui-même .

Cela a du sens.

Mais je me souviens avoir lu que vous ne devriez pas exposer les éléments XAML à la vue , mais uniquement exposer des ensembles de données que la vue lie et affiche à l'aide de DataTemplates.

Cependant, les convertisseurs semblent assez puissants (par exemple, comme ils sont utilisés dans Démo de modèle MVVM , voir & "Exemple de Messenger &" Après l'avoir décompressé) dans il peut convertir des objets en objets , par exemple Objets de message en objets FlowDocument, ou objets Client en objets de visibilité, ou objets d'état personnalisés en Images, etc.

Ainsi, si un modèle de vue doit prendre en charge les fonctionnalités d'un convertisseur de valeur , il devra exposer des éléments XAML et des propriétés telles que StackPanel, Visibility, Color, FlowDocument, etc., droite?

Quelqu'un voit-il une raison pour laquelle un ViewModel ne devrait pas exposer ces objets XAML riches comme le font les convertisseurs de valeur?

Answer 1

Parce que cela limite le ViewModel à être utilisé uniquement avec une représentation visuelle spécifique. Une fois que le ViewModel émet XAML, il place le contenu de conception dans le domaine du développeur. Cela signifie que le concepteur utilisant Expression Blend ne peut pas modifier les actifs de conception - et que le flux de travail concepteur / développeur est interrompu. Le fait de conserver le code XAML sur la page et d’utiliser des convertisseurs de valeur avec des modèles de données permet de séparer la conception du code.

Lorsque votre ViewModel expose un XAML spécifique, il limite également l'utilisation de ViewModel dans cette instance spécifique et la rend moins réutilisable.

Answer 2

N'oubliez pas que vous pouvez également utiliser DataTemplates. Je peux comprendre que garder ValueConverters à l’abri de MVVM, mais DataTemplates s’applique à transformer des objets en interface graphique.

Votre ViewModel peut exposer d'autres objets (ViewModels imbriqués, par exemple) à l'interface graphique. L'interface graphique peut utiliser <DataTemplate DataType="{x:Type SubViewModel}">... pour mapper ces objets sur l'interface graphique.

Answer 3

  

Quelqu'un voit-il une raison pour laquelle ViewModel ne devrait pas exposer ces objets XAML riches comme le font les convertisseurs de valeur?

Absolument, car cela mine tous les objectifs de MVVM:

1. Vous n'êtes plus testable par unité, du moins pas facilement.
2. Vous n'avez plus de séparation entre logique (modèle de vue) et présentation (vue). Les concepteurs et les développeurs ne peuvent donc pas facilement collaborer.
3. La maintenance du code est plus difficile car vous avez mélangé les problèmes.

Si je voyais un modèle de vue renvoyer une vue, je ne le classerais même pas comme MVVM.

Answer 4

Je pense qu'une des idées de mvvm / mvc / mvp etc. consiste à isoler le code de l'interface graphique dans un fichier / une classe. Si vous faites cela, pouvez-vous passer à une autre interface utilisateur sans réécrire les autres objets? Je pense que si vous transmettez des objets spécifiques à WPF, la réponse est non. C'est un jugement de valeur que vous devrez faire pour vous-même.

Answer 5

Il n’existe pas de règle absolue des 100% qui fonctionne pour ce concept ou pour d’autres concepts lorsque vous en discutez sans indiquer pourquoi l’esprit de la communauté a changé comme il l’a fait dans cette direction. Il n’existe pas de vérité ou de science "supposée" dans la "sagesse conventionnelle", quelle que soit la nouveauté ou la force de conviction à l'époque.

En d’autres termes, faites de votre mieux avec votre équipe, comme si c’était votre bien, vous êtes déjà bien plus touché par des préoccupations humaines que rien de plus réel que celui-là.