MVVM: Concevoir une architecture ViewModel avec ViewModels agrégés/selon

Question

Les WPF/MVVM alpha geeks dire:

1 View a 1 ViewModel. Parfois, plusieurs vues a 1 ViewModel (en utilisant un Wizard).

Si vous regardez mon image, vous voyez 6 Vues colorées/UserControls.

Les contrôles utilisateur JAUNE, VERT et ORANGE sont utilisés plusieurs fois dans mon application.

Les UserControls rose, bleu et rouge sont utilisés une seule fois.

Questions:

1. devrais-je les faire UserControls aussi? Si oui, pourquoi si je ne les réutilise pas.

2. Supposons qu'il s'agisse de 6 UserControls, doivent-ils partager le même ViewModel? OU chaque vue doit-elle posséder son propre ViewModel?

A.) Créer classCode dans GREEN Envoyer le code de classe JAUNE

B.) Sélectionner le code de classe JAUNE changement élève actuel en BLEU

C.) Sélectionner élève en cours en BLEU détails Changement des élèves dans les documents RED Changement des élèves dans ORANGE

D.) Créer élève ROSE Envoyer élève BLUE

E.) ... beaucoup plus

Est-ce que le chemin à parcourir, tir autour des données avec une classe Messenger pour maintenir les relations à jour?

Il y a un défaut majeur pour moi:

créer un PupilViewModel mais je ne sais pas dans le NewPupilViewModel (ROSE) wether un SchoolclassCodeViewModel existe dans le jaune UserControl donc je pourrais ajouter mon nouveau PupilViewModel au BLEU UserControl .

SchoolclassCodeViewModel 1: N PupilViewModel.

3. Comment pourriez-vous résoudre ce problème?

Answer 1

approche de Dan est à peu près identique à ce que je vais suggérer. Pour répondre aux questions spécifiques:

1) Je les ferais UserControls s'il y a une quelconque complexité dans leur mise en page. Premièrement, il est plus facile de tout faire de façon constante. pour un autre, cela facilite la lecture de la disposition de ce contrôle dans Expression Blend sans avoir à instancier une fenêtre entière.

2) Il existe un modèle de vue d'application pour toute la fenêtre. Il contient des propriétés pour les vues qui en ont besoin:

ObservableCollection<ClassCodeViewModel> ClassCodes 
ClassCodeViewModel NewClassCode 
ClassCodeViewModel SelectedClassCode 
PupilViewModel NewPupil 
PupilViewModel SelectedPupil 

2A) ClassCodeViewModel expose une CreateCommand qui déclenche un événement quand il est exécuté. Le modèle de vue de fenêtre gère cet événement et effectue la mise à jour appropriée à ClassCodes lorsqu'il est déclenché. 2B) Le modèle de vue de code de classe contient une collection observable de modèles de vue pupille. La propriété SelectedItem dans la propriété SelectedClassCode dans le modèle de vue de fenêtre que le SelectedItem sur le modèle de vue de codes de classe est lié. La vue bleue est liée à SelectedClassCode.Pupils.

2C) De même, le modèle de vue de fenêtre contient une propriété SelectedPupil à laquelle la propriété SelectedItem de la vue bleue est liée. La vue rouge est liée à SelectedPupil. 2D) Ceci est traité de la même manière que dans 2A: le modèle de pupille soulève un événement et le modèle de vue fenêtre le gère.

3) Le modèle de vue pupille contient une propriété booléenne CanCreate. Ce n'est pas utilisé dans la vue rouge. Le modèle de vue de fenêtre définit NewPupil.CanCreate dans le setter de SelectedClassCode.

Vous n'avez pas demandé, mais la vue orange est liée à la propriété Documents de SelectedPupil, ce qui est probablement (en fonction de quels documents sont réellement) une collection observable d'objets DocumentViewModel.

Peut-être que j'ai travaillé dans les domaines de MVVM pendant trop longtemps, mais cela me semble extrêmement simple.