ViewModel en tant que membre de ViewModel

Question

J'utilise MVVM Light Toolkit pour apprendre le modèle MVVM. Cependant, je n'ai pas été capable de résoudre le problème des commandes usercontrols dans le scénario des contrôles. Par exemple, dans une application Timesheet, disons que nous avons un contrôle appelé NewUnitOfWork. Lors du premier chargement, un panneau avec un ListBox avec une liste de projets est chargé en tant que contenu de NewUnitOfWork. L'utilisateur clique sur un. Un nouveau panneau est remplacé par un ListBox contenant les tâches possibles pour ce projet. Une tâche est sélectionnée et un nouveau panneau est chargé qui contiendra des contrôles pour entrer des données pour la tâche choisie du projet choisi. Par conséquent, l'élément sélectionné dans un contrôle utilisateur est transmis aux deux autres contrôles utilisateur, qui sont à leur tour convertis en tant que contenu du contrôle (ou fenêtre) NewUnitOfWork.

Si chaque contrôle a son propre ViewModel, nous devons passer la valeur sélectionnée d'un ViewModel à l'autre, etc.

J'ai fonctionner dans une situation unique utilisateur à l'aide des variables globales (via un « service »). Cependant, il y a des problèmes de concurrence avec cela et ce n'est pas une bonne solution. C'est sous-pair.

J'ai vu plusieurs fois la suggestion sur ce forum d'avoir ViewModel en tant que membre d'un autre ViewModel. Bien que cela résout le problème, je crois que c'est une violation du modèle MVVM. Un autre ViewModel n'est pas une fonctionnalité liée à l'interface utilisateur que le ViewModel doit être directement.

Donc. Est-ce que quelqu'un a trouvé une façon propre à MVVM de faire ce genre de chose?

Vive

Answer 1

S'il vous plaît toujours garder à l'esprit que MVVM est juste un modèle et il est conçu pour vous aider à séparer votre interface utilisateur et la logique. N'ayez pas peur de «violer le modèle» si cela contribue à augmenter la testabilité ou la maintenabilité de l'application. Avoir un maître ViewModel avec plusieurs ViewModels enfants est très pratique si vous avez une interface utilisateur complexe. Le ViewModel principal peut être responsable de la gestion des contrôles de l'interface utilisateur de niveau supérieur et de la coordination des machines virtuelles enfant, tandis que les autres ViewModels sont responsables de la communication avec les sous-régions de votre interface utilisateur. En outre, si vous disposez d'une interface utilisateur très complexe avec les multiples couches d'interface utilisateur d'imbrication, vous pouvez implémenter une infrastructure pour automatiquement répercuter tous les événements des machines virtuelles maître vers les machines virtuelles enfants. Et de cause, vous pouvez essayer d'utiliser l'un des frameworks MVVM les plus avancés. Par exemple Catel implémente un modèle assez complet pour résoudre de telles situations avec des machines virtuelles imbriquées.

Answer 2

Je ne vois pas de problème avec ViewModels référence à d'autres ViewModels (basées sur mon expérience avec TreeViews). Jetez un oeil à tout article sur TreeView et MVVM. Vous verrez que chaque nœud est un ViewModel, qui référence une collection de nœuds enfants, qui sont ViewModels. Essayer de le faire sans références VM-VM serait un cauchemar.

Josh Smith http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx

Answer 3

J'utilise la configuration suivante:

Un « maître » VM avec une « collection » VM et une machine virtuelle « détails » comme propriétés imbriquées.

La machine virtuelle maître est liée à une vue utilisée en tant que masque principal. Cette vue maître-détail est composée de deux autres vues.

Je trouve l'installation très soignée car elle me permet de mettre des critères de recherche dans la vue principale (modèle) et de garder les autres View (Model) s propres.

Je ne vois pas comment cela pourrait briser le modèle.