What creates the boundaries of a viewmodel

Topics: Getting Started, UI Architecture
Oct 30, 2012 at 2:01 PM

Hello, I've looked through the documentation and examples for CM - but one thing about MVVM is a for me. 

What decides the "hierarchy"  of the viewmodels and what each viewmodel should contain?

By hierarchy, I mean an application might have a main chrome, menus and submenus, perhaps toolbars, Is the main chrome ("shellview") supposed to contain viewmodels for All the items which are or might become visible due to user interfaction? 

By the second half of the question I'm wondering if the division of the viewmodels - is the diviison of things into user controls the determining factor or is there some other good pointer?

For example, if the application contains a menu, does binding related tothis menu have to be in a menuviewmodel or in shellviewmodel, why would i pick one over the other?

Oct 30, 2012 at 4:38 PM

the hierarchy can be what works for you.  Most will create a viewmodel for the items being dropped into the shell.. So for the Menu you might have a MenuView.xaml (usercontrol) which in turn has a MenuViewModel which will have a service that allows for other modules to subscribe to that service either thru IOC, EventAggregator, some other implementation. 

using usercontrols will do this exactly.  MVVM is pretty much all ViewModels and using CM is a ViewModel first framework, but it can be View First but works better and helps the developer more, ViewModel first imo.  It's not Model View ViewModel for nothing (MVP is also the same thing).

Testability would be one of the deciding factor for placing directly in ShellViewModel over creating a MenuViewModel, etc...

MVVM doesn't have to force you into that mindset of not having anything in the codebehind of the view either.  If it affects the view it can be done in the codebehind. Some will disagree with this too..