The best approach to create new window in WPF using MVVM

In the neighbour post: https://stackoverflow.com/questions/501886/wpf-mvvm-newbie-how-should-the-viewmodel-close-the-form/2100824#2100824 I've posted my vision how to close windows with MVVM usage. And now I have a question: how to open them.

I have a main window (main view). If user clicks on the "Show" button then "Demo" window (modal dialog) should be displayed. What is a preferable way to create and open windows using MVVM pattern? I see two general approaches:

The 1st one (probably the simplest). Event handler "ShowButton_Click" should be implemented in the code behind of the main window in way like this:

        private void ModifyButton_Click(object sender, RoutedEventArgs e)
        {
            ShowWindow wnd = new ShowWindow(anyKindOfData);
            bool? res = wnd.ShowDialog();
            if (res != null && res.Value)
            {
                //  ... store changes if neecssary
            }
        }

1. If we "Show" button state should be changed (enabled/disabled) we will need to add logic that will manage button state;
2. The source code is very similar to "old-style" WinForms and MFC sources - I not sure if this is good or bad, please advise.
3. Something else that I've missed?

Another approach:

In the MainWindowViewModel we will implement "ShowCommand" property that will return ICommand interface of the command. Comman in turn:

• will raise "ShowDialogEvent";
• will manage button state.

This approach will be more suitable for the MVVM but will require additional coding: ViewModel class can't "show dialog" so MainWindowViewModel will only raise "ShowDialogEvent", the MainWindowView we will need to add event handler in its MainWindow_Loaded method, something like this:

((MainWindowViewModel)DataContext).ShowDialogEvent += ShowDialog;

(ShowDialog - similar to the 'ModifyButton_Click' method.)

So my questions are:

1. Do you see any other approach?
2. Do you think one of the listed is good or bad? (why?)

Any other thoughts are welcome.

Thanks.

Some MVVM frameworks (e.g. [MVVM Light][1]) make use of the [Mediator pattern][2]. So to open a new Window (or create any View) some View-specific code will subscribe to messages from the mediator and the ViewModel will send those messages.

Like this:

Subsription

Messenger.Default.Register<DialogMessage>(this, ProcessDialogMessage);
...
private void ProcessDialogMessage(DialogMessage message)
{
     // Instantiate new view depending on the message details
}

In ViewModel

Messenger.Default.Send(new DialogMessage(...));

I prefer to do the subscription in a singleton class, which "lives" as long as the UI part of the application does. To sum up: ViewModel passes messages like "I need to create a view" and the UI listens to those messages and acts on them.

There's no "ideal" approach though, for sure.

[1]: http://www.galasoft.ch/mvvm/getstarted/ "MVVM Light" [2]: http://en.wikipedia.org/wiki/Mediator_pattern

I was thinking about this issue recently too. Here's an idea I had if you use Unity in your project as a 'container' or whatever for dependency injection. I guess normally you'd override App.OnStartup() and create your model, view model, and view there, and give each the appropriate references. Using Unity, you give the container a reference to the model, then use the container to 'resolve' the view. The Unity container injects your view model, so you never directly instantiate it. Once your view is resolved, you call Show() on it.

In an example video I watched, the Unity container was created as a local variable in OnStartup. What if you created it as a public static readonly property in your App class? You could then use it in your main view model to create your new windows, automatically injecting whatever resources the new view needs. Something like App.Container.Resolve<MyChildView>().ShowDialog();.

I suppose you could somehow mock the result of that call to the Unity container in your tests. Alternatively, perhaps you could write methods like ShowMyChildView() in the App class, which basically just does what I described above. It might be easy to mock a call to App.ShowMyChildView() since it would just return a bool?, eh?

Well, that might not really be any better than just using new MyChildView(), but it's a little idea I had. I thought I'd share it. =)

I'm a bit late, but I find existing answers insufficient. I will explain why. In general:

• it's ok to access ViewModels from View,
• it's wrong to access Views from ViewModels, because it introduces circular dependency and makes the ViewModels hard to test.

Benny Jobigan's anwer:

App.Container.Resolve<MyChildView>().ShowDialog();

this actually does not solve anything. You are accessing your View from ViewModel in a tigtly coupled fashion. The only difference from new MyChildView().ShowDialog() is that you went trough a layer of indirection. I don't see any advantage over directly calling the MyChildView ctor.

It would be cleaner if you used interface for the view:

App.Container.Resolve<IMyChildView>().ShowDialog();`

Now the ViewModel is not tigtly coupled to the view. However I find it quite impractical to create interface for each view.

arconaut's anwer:

Messenger.Default.Send(new DialogMessage(...));

it's better. It seems like Messenger or EventAggregator or another pub/sub patterns are universal solution for everyhing in MVVM :) The disadvantage is that it's harder to debug or to navigate to DialogMessageHandler. It's too indirect imho. For example, how would you read output form the Dialog? by modifying DialogMessage?

My Solution:

you can open window from MainWindowViewModel like this:

var childWindowViewModel = new MyChildWindowViewModel(); //you can set parameters here if necessary
var dialogResult = DialogService.ShowModal(childWindowViewModel);
if (dialogResult == true) {
   //you can read user input from childWindowViewModel
}

DialogService takes just dialog's ViewModel, so your viewmodels are totally independent from Views. At runtime, DialogService can find appropriate view (using naming convention for example) and shows it, or it can be easily mocked in unit tests.

in my case I use this interfaces:

interface IDialogService
{
   void Show(IDialogViewModel dialog);
   void Close(IDialogViewModel dialog); 
   bool? ShowModal(IDialogViewModel dialog);
   MessageBoxResult ShowMessageBox(string message, string caption = null, MessageBoxImage icon = MessageBoxImage.No...);
}

interface IDialogViewModel 
{
    string Caption {get;}
    IEnumerable<DialogButton> Buttons {get;}
}

where DialogButton specifies DialogResult or ICommand or both.

Take a look at my current MVVM solution for showing Modal Dialogs in Silverlight. It solves most of the issues you mentioned yet its completely abstracted from platform specific things and can be reused. Also i used no code-behind only binding with DelegateCommands that implement ICommand. Dialog is basically a View - a separate control that has its own ViewModel and it is shown from the ViewModel of the main screen but triggered from the UI via DelagateCommand binding.

See full Silverlight 4 solution here Modal dialogs with MVVM and Silverlight 4

I use a controller which handles all information passing between views. All viewmodels use methods in the controller to request more information which can be implemented as dialogs, other views etc.

It looks something like this:

class MainViewModel {
    public MainViewModel(IView view, IModel model, IController controller) {
       mModel = model;
       mController = controller;
       mView = view;
       view.DataContext = this;
    }

    public ICommand ShowCommand = new DelegateCommand(o=> {
                  mResult = controller.GetSomeData(mSomeData);
                                                      });
}

class Controller : IController {
    public void OpenMainView() {
        IView view = new MainView();
        new MainViewModel(view, somemodel, this);
    }

    public int GetSomeData(object anyKindOfData) {
      ShowWindow wnd = new ShowWindow(anyKindOfData);
      bool? res = wnd.ShowDialog();
      ...
    }
}

My approach is similar to adrianm’s. However, in my case the Controller never works with the concrete View types. The Controller is completely decoupled of the View - in the same way as the ViewModel.

How this works can be seen in the ViewModel example of WPF Application Framework (WAF).

.

Best Regards,

jbe