Master details using a popup dialog and Prism4

Versions of this question have been asked, but I don't think it's a duplicate as such. I am building an LOB application in C#/Prism4 and I'm trying to get the architecture right from day one. The app wi开发者_如何学JAVAll (eventually) have quite a few master/details screens plus edit screens with embedded grids that can be edited. For example: display a list of users with the ability to add or edit via a popup screen.

At the moment, I'm thinking a simple solution would be to have the dialog as a hidden panel databound to the same viewmodel with its visibility controlled by databinding. To edit a user (using above example), make a copy of the data to edit then set a IsInEditMode flag to true to show the dialog. Normal commanding can then capture the 'save'/'cancel' buttons to update the model (or not).

Whereas this sounds simple to implement, it feels a bit wrong. There is a separation of concerns, it just feels like the viewmodel is being multiplexed.

I have come across the Prism InteractionRequest guidance, but that seems more geared towards simple popups ('Are you sure you want to cancel?').

I need a solution that scales across tens of screens. It has to be simple and easy to maintain.

Thanks in advance.

The general approach is to have a so called dialog service with the interface something like this:

public interface IDialogService
{        
    bool? ShowDialog<TViewModel>(TViewModel viewModel);
}

And whenever you need to show a dialog you call the ShowDialog method passing a view model for the dialog. And the service takes of the rest. It can show a hidden panel, real dialog window or popup - it depends on the implementation and the calling side doesn't know anything about it.

In my opinion, the master details deserves a view of its own (the VM part might be necessary if the details are of multiple model objects).

That said, I would definitely use the PopupRegionBehavior, that was part of the RI for Prism 2.2. This is particularly useful for this scenario, as it allows you to register the master details View in a specific region (and if you ever decide to pull the details into the Shell, this will still work).

There are many threads in the Prism forum at codeplex that talk about this.

I would not agree that your dialog box always should have it's own VM, the calling side can just pass it's own DataContext, this is how you do not have to take care of syncing maser/child ViewModel and it has nothing to do with the separation of concerns. For example you have an user profile form (maser) and there is modal dialog address - if you pass profile's vm after your dialog is closed your address-related properties and view fields are updated automatically (enjoy the binding).