I've lately been involved with WPF and looked into MVVM. I understand that view model shouldn't be aware of view.

However, sometimes I come across situation where my initial instinct is to write property in view model something like public bool ShowDialog { get; private set; } or public bool ShowPopUp { get; private set; }

Does it suggest that view's responsibility is creeping in view model and I should approach differently?

2 Answers 2


Sometimes this can just be a naming issue.

For example, calling something ShowDialog in the ViewModel when what you mean is AskTheUserForAFilePath, which is independent of how the View handles that request. Similarly, ShowPopup when you mean InformTheUserOfThisEvent.

The end result of the communication will be the same but it allows multiple Views to handle the same interaction with the ViewModel in their own ways.

  • consider 2 views, one you click save and a file selector pops up. the second shows the file selector first and then saves at stage 2.
    – Ewan
    Feb 16, 2018 at 22:28
  • You made me think about something. If I want to display popup to ask user confirmation like "Are you sure? Yes/Cancel" before submitting form, so instead of having bool [Ask/Show]Confirmation it should be bool UserHasConfirmed. So instead of naming properties like they are commands, they should refer state of the view.
    – Siim Haas
    Feb 17, 2018 at 12:34


If you were doing MVC I would say no. the purpose of the view model is to provide a model of the view which you can manipulate, query and test in code. It doesn't contain any business logic. But can contain view logic. ie when this is hidden show that.

You may well have a one to one mapping of View to ViewModel

In MVVM the view model tends to contain more businessy logic. You are expected to be able to apply multiple views to a single view model and have them all work. A ShowDetail property might make no sense for some Views

We then also have the practical aspect of WPF. Where Razor copes well with complex bindings,

visiblity=@{..complex expression with multiple conditionals and function calls}

Wpf doesnt,

Visiblity="{Binding PropertyWhichIsTheCorrectType Converter={Static/Relative namespace:thingIDeclaredinXAMLEarlierMaybe}}"

It makes you life far easier if you can just add a property to your VM and put the logic there.

You also have controls which are not fully supportive of the MVVM pattern, Behaviours, Converters and code behind etc. All of which can make your code messy if you don't have a common approach which you reuse across your codebase.

In conclusion I think that ShowDialogue properties are not the worst way to code. You are better off edging towards a more MVC+VM-C approach than trying to force WPF into a purist MVVM pattern

  • 1
    This answer is not bad. However, I always thought in plain MVC, there is no "View Model" - that is AFAIK a term from MVVM. Do you meant "MVP"?
    – Doc Brown
    Feb 16, 2018 at 12:11
  • I think there is more than one MVC, in the old days C literally meant your keyboard! In "asp.net MVC"(c) its common practice to use ViewModels as well as Models to expose this kind of logic. Given the WPF tag I think its a good comparison.
    – Ewan
    Feb 16, 2018 at 12:35

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.