Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Should a child window have it's own data context (View-Model) or use the data context of the parent? More broadly, should each View have its own View-Model? Are there are any rules to guide making that decision? What if the various View-Models will be accessing the same Model?

I haven't been able to find any consistent guidance on my question. The MS definition of MVVM appears to be silent on child windows.

For one example, I have created a warning message notification View. It really didn't need a data context since it was passed the message to display. But if I needed to fancy it up a bit, I would have tapped the parent's data context.

I have run into another scenario that needs a child window and is more complicated than the notification box. The parent's View-Model is already getting cluttered, so I had planned on generating a dedicated VM for the child window. But I can't find any guidance on whether this is a good idea or what the potential consequences may be.

FWIW, I happen to be working in Silverlight, but I don't know that this question is strictly a Silverlight issue.

share|improve this question
up vote 4 down vote accepted

I guess it depends. On the project I am currently working on, we have used both approaches. I suppose it comes down to how related the child window's functionality is to the parent. If the new window is mostly supplemental, such as a prompt or minor input dialog, I have simply used the parent's data context because the data being provided through that dialog was still very relevant to the parent's functionality. On the other hand, if the new window is a significant feature in itself, it may be more appropriate to use a new data context that reports back to the parent (if applicable). Think of it this way, when designing a class, when is it appropriate to break out functionality into another class? You don't necessarily want an unwieldy view-model with a bunch of unrelated functionality lumped together.
Unfortunately, this has turned into a pretty fuzzy answer that depends on your best judgment.

share|improve this answer

The rule I would use is one ViewModel per View. If it's something very generic, than it's a Control rather than a specific View. In that case it would use parent View's DataContext. MessageBox warnings could also be shown using some sort of Service class that you would inject into ViewModels. ViewModels can also have other ViewModels nested in them, for example when you are using Grid-like controls.

share|improve this answer

I feel like any child view should have its own view model. I say this because if you were you take out the child view from the parent view you would have redundant data (which was intended for the child view) sitting in the parent view model. It seems to me that for this reason alone it would make the most sense to have a view model for each.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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