Lanuching New Window In WPF MVVM

Jan 2, 2011 at 10:46 PM

Doing code-behind in WPF, I know how to click on a button on a window and within the click event, create an instance of another window, show that window and hide the current window. When finished with the new window, a click on a button on that window would result in the showing of the original window and then the closing of the new window. This pattern could be repeated to multiple levels of windows (with only the newest one visible).

In my MVVM solution, I have three projects, View project, ViewModel project and a Model project. The ViewModel project has a reference to the Model project and the View project has a reference to the ViewModel project. This project structure was suggested in a new book on MVVM that was published in December, 2010 (and the book is not very good). The author’s intent was to maintain the discipline of the MVVM pattern.

The Views are aware of the other views but the ViewModels are not aware of the views. Therefore, I do not see how a ViewModel could launch a new view (WPF window). For a view to launch another view would require code-behind on the view, which is breaking the MVVM pattern (as I understand it.)

I have searched of examples but have not found any. Life would be so much easier if there were a simple sample WPF MVVM app with a starting window that has two or three child windows and they in turn had a two or three child windows.

Jan 8, 2011 at 12:09 PM


Firstly, when implementing pure MVVM you really ought not to use click events to manage this form of interaction, instead you should bind buttons to Commands. In your situation where ViewModels are not able to instantiate new Views I would recommend that you write a "View Controller" class which is responsible for creating/managing Views and exposes ICommand instances (usually something akin to a DelegateCommand) which create the appropriate view when a command is executed. This "View Controller" class is passed to the ViewModel (preferably via injection) and exposed on the ViewModel (either directly or indirectly). The button responsible for creating the child view is then bound to the command much like any other type of binding; i.e. <Button Command="{Binding ViewController.ShowWindowCommand}"/>. This will result in code being executed within your ViewController class (which is responsible for creating/managing views) when a user clicks a button in your view, therefore not breaking the strict View/ViewModel separation. Furthermore, you can employ the CommandParameter property to pass context to the execution of the command.

Secondly, it seems you have a definite process in mind when the user clicks a button (hide the current window, show a new window, wait for interaction, close new window, show original window). If you have such long-running process flows in your application, I would suggest you look at Ron Jacob's recent Channel 9 screencast on writing State-Machine Driven WPF UIs as it would certainly provide a neat solution to this kind of process.

Hope it helps.


Jan 8, 2011 at 7:15 PM

Ian, thank you for your reply.  I am working hard to both understand the MVVM pattern and the reasoning that supports it. 

Considering separation of concern, I understand that the View display the data while the ViewModel supplies and manages data. I do not have a solid understanding of which branch should be responsible for the interaction between the various views. This lack of understanding may simply be due to my lack of knowledge.

I have tried for hours to design a ViewController without success.

However and wherever it is performed, the following tasks need to be performed: the new window (view) is instantiated. Optionally data may be needed to be sent to the new window, either at construction or after the window instance is created. The parent window needs to be declared the owner of the new window. The new window needs to be shown (“newWindow.Show();”). The parent window needs to be hidden.

Do you know where I may obtain a sample application that utilizes a ViewController? This seems so fundamental that many developers attempting to master the MVVM pattern would find it helpful.

Below is a code snippet where I employed some code-behind to solve the issue. ( I know that it will probably get me voted off the island.)

 private void btnResults_Click(object sender, RoutedEventArgs e)
            if (viewModel.DataIsOk())
                object results = viewModel.GetViewModelData("Questionaires");
                SurveyResultsView window = new SurveyResultsView(results);
                window.Owner = this;
                this.Visibility = Visibility.Hidden;


Jan 10, 2011 at 3:25 PM
public interface ISurveyResultsController
   void ShowWindow(object results);

This is a very specific controller, and I'm not suggesting you have a separate controller for every View this way, but I think it does a better job of illustrating what you'd do than to illustrate any of the more generalized designs. This interface is injected into you're ViewModel so that you're ViewModel has no direct coupling to any UI. In tests this would be mocked out to do what ever is necessary for testing without creating any UI controls that are difficult to automate when testing. In production code the implementation of this interface would be pretty identical to what you have above in your event handler.

The more generalized approach would be something that would allow you to write code more along the lines of the following:

IView view = controller.CreateViewFor<SurveyResultsViewModel>();
view.ViewModel.Results = results;

There's lots to flesh out from this, but for the most part, that's where the power of this pattern lies, and giving a full implementation of the idea isn't really possible in a post like this :).

Jan 10, 2011 at 6:32 PM

I really do appreciate when I get responses to my questions. The problem is that the responders tend to assume that I know more than I do. I have read and re-read the last response and I have searched the web (“wpf iview” and “mvvm iview” and “mvvm viewcontroller”) and I am still at a loss.

I found a real neat diagram at (WPF Applications Framework – WAF) but not a complete example.

Does anyone have a complete example? Is there a web-site that covers the issue of MVVM screen management?

Jan 10, 2011 at 7:03 PM

Sorry, it's never possible to fully understand the level of understanding, and "dumbing" down a response too much can offend some people.

IView isn't something you can search for, as it's a name made up on the spot to illustrate one design. As I said, I can't give you an implementation for IView or the implied IController from the sample code, as this generalized design is really too complex for a post. I'm trying to illustrate design concepts here, not give you a complete implementation. There's lots of implementations out there, some that won't resemble the interfaces I just gave at all (for instance,

Start with the basics. The ISurveyResultsController is the most basic, being very specific to the scenario you've set out to solve. I told you how to implement it... the code from your event handler goes in almost verbatim into the ShowWindow implementation. All that's missing to get this up and running in a sample application is how to inject the service into your ViewModel. That's where MVVM frameworks come in to help, but to make things simple without a framework you could simply do something like this.

public SurveyResultsView()
   var controller = new SurveyResultsController(this);
   this.DataContext = new SurveyResultsViewModel(controller);

Are you trying to understand the concepts, or do you want a solution? Most of the MVVM frameworks will provide a solution here, each in their own way, but most are based around this concept of a View Controller. If you just want to understand the concepts, if this didn't enlighten you ask some more specific questions so I can elaborate for you.

Jan 10, 2011 at 10:57 PM

To begin with, I am not looking for a solution but rather an understanding of the pattern.

The following is what I understand to be true:

The View is dependent on the ViewModel.

Via binding from the View is executing a command in the ViewModel.

In this case, the command is to cause the instantiation of another View, an object that is not exposed directly to the ViewModel.

It is at this point that I start to loss control. The following interface was suggested:

public interface ISurveyResultsController
   void ShowWindow(object results);


It was suggested that “This interface is injected into you're ViewModel so that you're ViewModel has no direct coupling to any UI.” I do not have a clue as to how to do this. Is this interface declared in the project containing the Views or the project containing the ViewModels? Where is this interface implemented? Are we trying to get to the point where we are sending from the View project to the ViewModel “call me when you want me to create this view”?

Jan 11, 2011 at 2:06 PM

I showed the simple manual way to inject this.

public SurveyResultsView()
   var controller = new SurveyResultsController(this);
   this.DataContext = new SurveyResultsViewModel(controller);

This I think is the best way to illustrate the concepts, but it's not how you'd do things normally. Normally you'd rely on an IoC (Inversion of Control) Container (such as Autofac/Unity/StructureMap/etc.) or similar mechanism (such as MEF). Entire MVVM frameworks are built around these concepts (Onyx, Caliburn, and MVVM Light to name just a few) which you could look at for much more complete implementations of the concept, but really, the above is enough to give you insight into how the pattern(s) work.

To answer some specific questions:

Is this interface declared in the project containing the Views or the project containing the ViewModels? This is not really a meaningful question, as patterns don't care about details like this. All of the code can be in a single project (assembly) and you'll be following the pattern correctly, for instance. If you're going to decide to seperate the Views and ViewModels into different assemblies (I'm not sure that I would, BTW), then the fact that the Views project is going to reference the ViewModels project and not the other way around means that this interface would have to go in the ViewModels project, or in a third project.

Where is this interface implemented? This is sort of like the last question, and not really a meaningful question. It doesn't really matter where you implement it. However, since the implementation is going to have to have a hard dependency on the View that will determine where it can and cannot go, just like in the last question.

Are we trying to get to the point where we are sending from the View project to the ViewModel "call me when you want to create this view"? Sort of, yes. I say sort of because in the more generalised implementation the ViewController will usually be decoupled from the concrete Views as well by having the controller pick a View based on either configuration or convention. So the real point is that we're getting to the point where the ViewModel doesn't interact with the View, but rather interacts with an intermediary (a "service") that is passed (injected) into the ViewModel. By doing so the ViewModel is no longer coupled to any specific View. This allows it to be reused with multiple Views, and also allows it to be unit tested without any need to do UI automation, which is a brittle and difficult way to do automated testing.

Jan 11, 2011 at 2:14 PM

I just reread your original post, and maybe I can provide better answers directly related to the project layout that you are using.

Define the ISurveryResultsController interface in the ViewModels project. It has to be here since your ViewModels need to reference this interface and this project does not reference the Views project.

Implement the SurveyResultsController class in the Views project. It has to be here since the SurveyResultsController will reference the SurveyResultsView.

Keep in mind that these decisions are not relevant to the pattern, but will help you in implementing the naive design I've discussed here, and therefore may help you to understand the pattern(s).