PRISM/MEF: How can 2 windows' viewmodels talk to each other?
Basically, I'm not sure where to start:
I have my Shell.xaml window. I also have my Popup.xaml window.
I set the Shell.xaml to import the PopupWindow then when the PopupWindow Loaded event fires, it does:
Popup.Owner = this;
Popup.Show();
Now, I need to be able to have the PopupWindow's ViewModel communicate with the Shell.xaml. Basically, I need to be able to have the PopupWindow tell the Shell's ViewModel information the user inputs.
Update:
In keeping this decoupled, I don't want to pass in any instance of the C开发者_如何学Client's viewmodel to the popup, I'd much rather have the Popup's ViewModel somehow have a way of communicating to the Client's ViewModel without knowing who it is actually talking to.
Have a look at the event aggregator in Prism. The aggregated events in Prism are intended as a means of facilitating decoupled, inter-viewmodel communication. If you are going for "pure" MVVM, I think that it would go something like this:
- Your ViewModel publishes a message (interaction request) that it want's to display a popup.
- Your View is listening for the message, and shows the popup window (decouples your viewmodel from understanding how prompts are displayed)
- Your ViewModel gets the results of the popup window (your popup window is just a view, and should know nothing about raising aggregate events)
- Your ViewModel raises a Prism Aggregate Event (an object containing the user input is the payload)
- Your shell is listening for that event.
I'm no PRISM/MEF guru but if I were attacking this problem I'd take a slightly different approach and add a tad more decoupling. Essentially you want the ViewModels of your windows (Shell and Popup) to communicate - windows (Views) should only communicate with the user and update properties (in a decoupled, model-bound fashion) on their ViewModels.
Once you're in this position then Shell's ViewModel can request the user information (say from a property) of Popup's ViewModel. Though, of course, they are not the ViewModels of either Shell nor Popup - they are merely ViewModels that these Views happen to be bound to :)
Purists would go even further and talk about message queues between the various communicating parties but one step at a time, methinks.
Dan
Edit
Following Michael's comment:
As I said I'm not expert in PRISM but I think it depends how far you want to go with the decoupling. There's nothing stopping the Client ViewModel creating and showing the popup and then querying the popup's ViewModel for data before disposing of it. It's not pure MVVM because your Client ViewModel is doing some fairly direct communication with the Popup and its ViewModel but it will work and it's not that big a sin.
I would go with a pragmatic approach in cases such as this where a natural dependency exists anyway. You still have the separation of View and ViewModel.
I imagine there are folks here who can instruct on a more decoupled approach - which I would also be interested in reading about.
精彩评论