I have spent two day trying to figure it out.
I have implemented two ways of working with mvvm popup windows
Example of the first aproach usage:
_childWindowController
.ShowDialogWithResult<AddNationalityPopup,AddNationalityPopupModel, AddNationalityResult>(
(result, a) =>
{
if (a.DialogResult.HasValue && a.DialogResult.Value)
{
if (result.NationalityCountryId.HasValue)
{
Background.NationalityCountryId = result.NationalityCountryId.Value;
Background.NationalityDescription = result.NationalityDescription;
}
}
});
The second approach:
var window = _childWindowController.CreateDialog<AddNationalityPopup>();
window.Closed += (sender, args) =>
{
if (args.DialogResult.HasValue && args.DialogResult.Value)
{
var result = (AddNationalityResult)window.Result;
if (result.NationalityCountryId.HasValue)
{
Background.NationalityCountryId = result.NationalityCountryId.Value;
Background.NationalityDescription = result.NationalityDescription;
}
}
};
window.ShowDialog();
In the first approach user of the service should know the types of view , view model, and result to be able to show dialog
In the second one interface is simplified a bit, but I still had to know to what type cast the result before its usage.
Have you ever faced the problem of showing d开发者_StackOverflowialog with view model?
How to improve the design of the window service?
Can you give an example of good implementation of the dialog service?
I recommend you take a look at User Interaction Patterns, as it goes over the different approaches you can take to handling user interactions in MVVM. An alternative to using an interaction service is to implement an interaction request object.
Another approach to implementing simple user interactions in the MVVM pattern is to allow the view model to make interaction requests directly to the view itself via an interaction request object coupled with a behavior in the view. The interaction request object encapsulates the details of the interaction request, and its response, and communicates with the view via events. The view subscribes to these events to initiate the user experience portion of the interaction. The view will typically encapsulate the user experience of the interaction in a behavior that is data-bound to the interaction request object provided by the view model.
This approach provides a simple, yet flexible, mechanism that preserves a clean separation between the view model and the view — it allows the view model to encapsulate the application's presentation logic, including any required user interactions, while allowing the view to fully encapsulate the visual aspects of the interaction. The view model's implementation, including its expected interactions with the user through view, can be easily tested, and the UI designer has a lot of flexibility in choosing how to implement the interaction within the view via the use of different behaviors that encapsulate the different user experiences for the interaction.
For an example of how implement this, I recommend you take a look at the Prism 4 library source code and its samples. The Prism library supports this pattern through the IInteractionRequest interface and the InteractionRequest class. The IInteractionRequest interface defines an event to initiate the interaction, while behaviors in the view bind to this interface and subscribe to the event that it exposes.
You could utilize the classes and interfaces defined in the Microsoft.Practices.Prism.Interactivity assembly, or use these types as a basis for implementing your dialog service.
精彩评论