CODEWITHSUNDEEP
wpfmvvmcommunicationviewmodelmediator
Elisabeth
Elisabeth

Reputation: 21206

MVVM: Design a ViewModel architecture with aggregated/depending ViewModels

The WPF/MVVM alpha geeks say:

1 View has 1 ViewModel. Sometimes Multiple Views has 1 ViewModel (using a Wizard).

If you regard my image you see 6 colored Views/UserControls.

The YELLOW,GREEN and ORANGE UserControls are used multiple times in my application.

The pink,blue and red UserControls are used only once.

Questions:

1. Should I make them UserControls too? If yes, why if I do not reuse them.

2. Assume those are 6 UserControls, should they share the same ViewModel? OR should each View have its own ViewModel?

A.) Create Classcode in GREEN Send class code to YELLOW

B.) Select class code in YELLOW Change current pupil in BLUE

C.) Select current pupil in BLUE Change pupil details in RED Change pupil documents in ORANGE

D.) Create pupil in PINK Send pupil to BLUE

E.)... many more

Is that the way to go, firing around data with a Messenger class to keep the relations up to date?

There is a major flaw for me:

I create a PupilViewModel but I do not know in the NewPupilViewModel(PINK) wether a SchoolclassCodeViewModel exists in the YELLOW UserControl so I could add my new PupilViewModel to the BLUE UserControl.

SchoolclassCodeViewModel 1 : N PupilViewModel.

3. How would you solve this problem?

alt text

Upvotes: 1

Views: 1127

Answers (1)

Robert Rossney
Robert Rossney

Reputation: 96730

Dan's approach is pretty much identical to what I was going to suggest. To answer the specific questions:

1) I would make them UserControls if there's any complexity to their layout at all. For one, it's easier to do everything consistently; for another, this makes it easier to play around with the layout of that control in Expression Blend without having to instantiate an entire window.

2) There's application view model for the entire window. It contains properties for the views that need them:

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

2A) ClassCodeViewModel exposes a CreateCommand that raises an event when it's executed. The window view model handles this event and does the appropriate update to ClassCodes when it's raised.

2B) The class code view model contains an observable collection of pupil view models. The SelectedItem property in the SelectedClassCode property in the window view model that the SelectedItem on the class codes view model is bound to. The blue view is bound to SelectedClassCode.Pupils.

2C) Similarly, the window view model contains a SelectedPupil property that the SelectedItem property of the blue view is bound to. The red view is bound to SelectedPupil.

2D) This is handled the same way that it's handled in 2A: the pupil view model raises an event and the window view model handles it.

3) The pupil view model contains a boolean CanCreate property. This isn't used in the red view. The window view model sets NewPupil.CanCreate in the setter of SelectedClassCode.

You didn't ask, but the orange view is bound to the Documents property of SelectedPupil, which is probably (depending on what documents actually are) an observable collection of DocumentViewModel objects.

Maybe I've been toiling in the fields of MVVM for too long, but this seems extremely straightforward to me.

Upvotes: 2

Related Questions