13

In my WPF application, I want to create a new view. Where should I do that - in ViewModel or Model?

The application is a (very simple for now) one-window form-like tool with single "send" button. In case if one of checkboxes is selected, new window using the same ViewModel should pop up to ask user for some additional details. For the purposes of this question, let's consider just the new window approach without considering another approaches like shown/hidden panel.

Ideally, in View there shouldn't be any code. In addition, as View does not have any logic in it VM would initially need to check if creating new view is needed, and - when it is - bouncing this responsibility back to View, leading to code bloat.

On the other hand, creating a new view in ViewModel violates principle that ViewModel shouldn't know anything about View.

So, is it better to create new views in View or ViewModel?

3
  • 1
    I don't really understand your question. What does "In View or ViewModel" mean? ViewModels don't create views, and views certainly don't create themselves. Commented Sep 12, 2016 at 16:13
  • 1
    I mean which of these layers should be responsible for creating new views - signal to do that must come from somewhere when action occurs. I excluded model from this question completely, because it shouldn't know anything about frontend at all.
    – Mac70
    Commented Sep 14, 2016 at 7:04
  • Maybe I don't understand your question correctly, both of them should not interfere with your view. If you wanted to create a new view in your viewModel, is there any reason why you are not using frames in xaml to change the Window content with a binding to your current viewModel?
    – Tolani
    Commented Sep 14, 2016 at 9:03

2 Answers 2

8

I use dependency injection and a IViewFactory injected into the view model to respect both constraints.

A ProductViewModel (for example) calls this.viewFactory.Show("Details", this) to open ProductDetailsView with itself as ProductViewModel. It could also open a view based on another view model with this.viewFactory.Show<ClientViewModel>().

The implementation (there are actually several for WinForms, simple Wpf Windows, a Wpf shell with tabs,...) is based on a StructureMap convention. The views designate their view model via an IView<ProductViewModel> interface.

So the view model doesn't know anything about the view except its role (default view, details view, ...), and the view contains no code to create another view. Also, the view models are in a separate assembly which doesn't reference any Wpf assembly.

13

Theoretical answer

If you have a ViewModel, actions that have cosmetic effects (e.g. highlight an item on mouseover) are the job of the View, while actions that have "real" effects (e.g. spawning a new window) are the job of the ViewModel.

As such, creating a new window is a job for the ViewModel. However, neither the View nor the ViewModel should know how exactly to create a Window, that's not part of their responsibilities and belongs to a different class.

You could argue that creating a new window is a job for the View. While I would disagree, there is little value in such a debate, because in practice it is not the end of the world if you place that code in the View, and it also isn't much work to move it to the ViewModel at a later point. The important part is that the logic for the creation of a new window is contained in an independent class, usually some kind of WindowFactory. The point of MVVM, MVP, MVC, etc is that you have classes with few and well defined responsibilities. That's why you don't add additional responsibilities to the View, ViewModel, or Model if you don't need to.

Under no circumstances does the creation of the Window belong to the Model, because the Model isn't even aware that there is something like a GUI.

Practical answer

This is about a "one-window form-like tool with single "send" button". So here's a shameless plug for a related answer of mine: Why use MVVM?

To summarize what that answer says: Keep it simple. Oh, and keep the theoretical answer above in mind to implement once your single button window starts to become more complex.

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.