Question

I’m trying to create a strategy for handling popup forms for use throughout any part of my application. My understanding so far is that I will need a single UserControl in the root of my MainWindow. This will be bound to its own ViewModel which will handle the messages that are sent within the app.

I’m using MVVM Light, and I’m fairly new to the Messenger class.

Imagine a Master/Details scenario, where a list a objects are contained within a ListBox. Selecting one of these items and clicking an Edit button would display a UserControl which covers the whole screen. The user can then edit the selected item, and click OK to commit the change.

I want the UserControl that is opened to be “generic” in a way that I can throw any (probably a ViewModel) at it… for it to render the ViewModel via a DataTemplate and handle all the object changes. Clicking OK will callback to the sending class and persist the change as before.

Some situations where this would be useful are…

1. Display error messages with no required user input (other than OK to close it)
2. Display an edit form for a data item
3. Confirmation dialogs (much like a standard MessageBox)

Can anyone provide any code samples of how I might acheive this?

Answer 1

When designing a UI with MVVM the goal is to separate the concerns of the View from the concerns of the ViewModel. Ideally, the ViewModel should not rely on any view components. However, this is the idal and another rule of MVVM is that you should design your application as you wish.

In the area providing a service showing dialogs there are two different approaches floating arround:

1. Implementing the DialogService on the View (e.g. see http://geekswithblogs.net/lbugnion/archive/2011/04/13/deep-dive-mvvm-samples-mix11-deepdivemvvm.aspx Sample 03).
2. Implementing a service component that does is not attached to the view (e.g. see http://blog.roboblob.com/2010/01/19/modal-dialogs-with-mvvm-and-silverlight-4/)

Both approaches rely on an interface that defines the functionality the service provides. The implementation for this Service is then injected into the ViewModel.

Also, do both approaches have their specific advantages and disadvantages.

• The first approach works also well for WP7, however, it requires a common view base class as this contains the implementation of the view service.
• The second approach works well for SilverLight and WPF and appleals as it keeps the service separate from the view and does not impose any restictions on the view.

Another possible solution is to use messaging to show the dialogs.

Whatever approach you are using try to keep the View and the ViewModel de-coupled by using an IoC (inversion of control) pattern, i.e. define an interface so that you can use different implementations. To bind the services into the ViewModel use injection, i.e. passing the service into the constructor of the ViewModel or by setting a property.