MVVM - Multiple ViewModels in a View?

[Jeremiah Morrill]

Laurent has encouraged me to speak out about my MVVM handicap ;).  I am slowly coming to up to speed with MVVM (currently in SL) and was wondering everyone's opinion on if it is good, bad or ugly to have multiple ViewModels in a single view.

-Jer

[Paul Stovell]

I see the VM (presentation model) as representing the state of the view. If there's some information shown in the UI, it should be represented in the VM. Having two VM's behind one view would probably mean extra overhead to communicate between them (as you should probably try to do it through an interface, to decouple them). It also means the VM isn't quite responsible for the state of the view, but rather part of te state of the view, which might make some of the boundaries difficult (people reading the code might not quite understand which responsibilities belong to each view).

But that's just a general opinion; for your specific case two VM's (especially if you can reuse existing ones) might make everything simpler. The best design pattern is always whatever is simplest, so if it works then stick with it. Sometimes we take these patterns too literally :-)

To remove all doubt, maybe prototype it using two VM's, then using just one, and then decide which is easier to understand and maintain?

On Wed, Nov 19, 2008 at 9:40 AM, Jeremiah Morrill <jeremiah...@gmail.com> wrote:

Laurent has encouraged me to speak out about my MVVM handicap ;).  I am slowly coming to up to speed with MVVM (currently in SL) and was wondering everyone's opinion on if it is good, bad or ugly to have multiple ViewModels in a single view.

-Jer

--
Paul Stovell
http://www.paulstovell.net

[Mike Brown]

I disagree with Paul, and agree with him at the same time. In the case of a user control within a larger view (a so-called composite view), it would make since for the user control to have it's own ViewModel that is discrete from the container's ViewModel. Basically, like Paul says, this will allow for reuse.

[Corrado Cavalli]

I agree with Mike opinion, when UI requires multiple ViewModels I use a ViewModel that exposes a series of sub-ViewModels that are databound to UI sub-areas (e.g.UserControls etc…) and coordinates sub-viewmodels.

This allows me to cleanly separate roles and results in a better testing.

 

Corrado

[Jaime Rodriguez]

+1 on the single view model with exposed ( bindable and notifiable) properties exposing sub-Viewmodels..

 

for me it comes to DataContext …   {there is only one inherited dataContext in the tree } … so I have one ViewModel and expose submodels from there..

Example, when I have a  page called “Create Customer Profile” which has 3 parts ( login credentials,  address, preferences ) …  I still have a single viewmodel that exposes it all..    If the parts are usercontrols, I might pass just the “subModel” to the UserControl..

 

 

Extending this thought and maybe going towards Jer’s question on multiple models, the one that I am still torn about is what I call “metadata” … which is read-only data used to populate the view…   
For example, imagine I have a real-estate app, and the UI shows a comboBox where a user will choose their  preference on rooms for the house (maybe list 1-10)..  

I is data driven (comes from database),  the SelectedItem is part of the ViewModel, no question there…   but what about this ‘read-only meta-data (with the 1-10 list)?’…   about half the time, I expose it via some {x:Static }  and the other half of the time, I expose it off the viewmodel (again so it flows w/ datacontext)..          How are others solving this??    

 

10x,

[Marlon Grech]

The way I solve this is by never having a BIG View. I try to decompose the UI in multiple chunks by making use of UserControls and then use a composite UserControl (usually this takes care of the Layouting) that adds all the little ones together. Usually this results in individual items being totally reusable and super simple.

--
Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

[Josh Smith]

Regarding where to put the static data, Jaime...  I put it on the ViewModel because I like to have the VM in charge of globalization concerns.  If you don't need to support multiple cultures, I think it's still beneficial to have the lists of static data on the VM because the View requires that data.  If our VMs are really going to be abstractions of a View, the VM needs to have this info on hand.  But, that's more "philosophical" than the point about centralizing your UI's globalization needs.

For Jer's question, I also am in agreement that nesting your ViewModels together is the way to go.  Trying to have one monolithic VM for your UI is fine if you always have simple little Views, but becomes impractical as the complexities of a View increase.

Josh

[Mike Brown]

It depends on circumstances. If I had a list of states, I might make that an x:Static...however it also makes sense even then to put it in the ViewModel. The convention I use is AvailableX/SelectedX (using the States example it would be AvailableStates/SelectedState.

[Josh Smith]

Having the list of read-only "shared" data exist once in memory is unrelated to how it is made available to the View, in my opinion.  The ViewModel can expose a static (in the sense of one-per-type) list of data on a per-instance level, no problem.  I think the more important distinction to make is why it belongs in the ViewModel as opposed to being some separate list of data floating around on its own in memory.  We've already discussed that, so I won't bother reiterating it.

Josh

[Mike Brown]

Indeed, we don't disagree...I came to the same conclusion while typing out my thoughts as you saw. ;)