In MVVM, the viewmodel communicates to the views by exposing observable values that the views subscribe to. As your UI grows and becomes more complex, the number of these observables grows and the amount of UI presentation logic increases.

In programming, if I have a class or a function that is becoming too large with too many responsibilities, I divide it into smaller classes or functions that are references by the parent class. I would assume the same concept would apply in MVVM if the UI is getting large with many views.

However, it's not clear how a child viewmodel would communicate to a parent, or how viewmodels would communicate to each other. Viewmodels are supposed to expose observable data -- would they be observing each other? This seems like a recipe for notification loops.

  • surely you have used components in MVVM?
    – Ewan
    Commented Jun 23 at 15:16

2 Answers 2


Essentially you have three choices. Listed in my order of preference:

  1. Top level VM with single View. Include smaller VMs as properties on the top level VM and wire everything up, Binding the View to TopLevelVM.ChildVM.Property

    Unless your application is truly huge I think this is always going to give you the most flexibility and ease of understanding. This is presentation logic after all and subject to whimsical changes.

  2. Componentize parts of the V and VM. For example a Button component completely encapsulates its View and ViewModel and offers up its own binding points. It can be reused infinitely reused.

    This requires more work; as you have to make sure you genericise your components and offer up sensible "result of operation" objects and events to the top level VM so that you aren't still doing all the work in the top level without having made the component so specialised that it will only be used once and is tightly coupled to the top level VM

  3. Use the mediator pattern. By passing in or having a global mediator you can fire all your events through that and have unrelated components subscribe to them.

    This is easy when you just have a couple of odd things, "when i add an item to the basket, the menu basket icon should update". But harder when you are running multiple complex events that need to work together in the right way to implement business rules.

  • About #1, what do you do when two views from two different childVMs need access to the same property? Are you forced to move that property up to the parent VM? Commented Jun 23 at 17:00
  • you only have one view in 1
    – Ewan
    Commented Jun 23 at 17:41
  • actually, i think i did answer a similar question before with examples : softwareengineering.stackexchange.com/questions/446737/…
    – Ewan
    Commented Jun 23 at 17:53
  • you'll have to imagine that items in the example is more a more complex VM
    – Ewan
    Commented Jun 23 at 17:55
  • 1
    omg functional UI declaration.... I think your first question is, is that even MVVM?
    – Ewan
    Commented Jun 23 at 22:39

Even if your UI is as complicated as this horror [see the original article here]

enter image description here

just bite the bullet and create as many properties on your ViewModel as required.

If you have repeated UI elements, you can simplify things a little by using an ItemsControl with a suitable data template, bound to a collection of sub-viewmodels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.