WPF/XAML - binding control commands to parent window's viewmodel? - wpf

Question

I have an application, and I have an assembly.
In the application, I have a window, and in the assembly I have a user control.
There is an instance of the user control in the window.
Both the user control and the window are backed by separate viewmodels.
In the user control, there is a button. The button should be enabled/disabled based on the state of the user control's viewmodel. When the button is clicked, processing needs to be done, based on the information in the user control's viewmodel, but it needs to be done by the window's viewmodel. (There are aspects of what needs to be done that are, and should be, outside of the scope of the user control.)
And here's the twist - this user control won't be used exclusively in this window, it might be used in another, or in a control that is used in a third. The user control can't be allowed to know what kind of window or control contains it, or is handling the process when its button is clicked.
So, what to do?
Define a command in the assembly, and bind the user control's button to it, passing the user control's viewmodel as the command parameter? How, then, do I bind the command to the window's viewmodel?
Or should I define the command in the user control's viewmodel, then raise an event to tell the parent window that the appropriate action needs to be taken?
It's not clear to me which is cleaner.

Answer 1

If you always know that the parent's property is going to be exposed the same with the same name, you can do something like this that has worked for me plenty of times:
Command={Binding Parent.DataContext.SomeCommand, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type UserControl}}}
This gets the usercontrol, then goes to the parent and gets that datacontext and binds it to that command. This works when the user control will be encompassed by many windows / controls that expose the same command (you could implement an interface here).
You could then pass the user control's viewmodel to the command (again, implement some interface) like so:
CommandParaemter={Binding }

Answer 2

You could use a Messenger structure to communicate between ViewModels.
MVVMLight contains one that you could use or you could write your own.
Before doing this make sure you did separate the responsibilities correctly or you'll end up with spaghetti-messages-code.

Answer 3

There should be hierarchy with your view models, just like you have with your controls. The main window has a child user-control. The Main View Model should be able to get connected with User Control View Model (and assign it if needed). Here is how I would do it:
public class MainVM:NotificationObject
{
// Make this a Notify Property
public UserVM userVM { get{return _userVM;}; set {_userVM = value; RaisePropertyChanged("userVM");}
public MainVM
{
userVM = new UserVM();
userVM.ExecuteCmd = new DelegateCommand (yourAction);
}
}
public class UserVM:NotificationObject
{
public DelegateCommand ExecuteCmd {get{return _executeCmd;} set{_executeCmd = value; RaisePropertyChanged("ExecuteCmd");
}
}
XAML:
<local:urUserCtrl DataContext={Binding userVM}/>
This is of course psuedocode

Answer 4

Sounds like a case for the Strategy pattern. http://en.wikipedia.org/wiki/Strategy_pattern
Define an interface for a strategy object that can be assigned to the UserControl's viewmodel, (or used to initialise it). The interface defines whatever properties/methods/events are required to enable the strategy object to retrieve from the UserControl viewmodel the data needed for the processing, plus a means of returning the result of the processing back to the UserControl viewmodel.
Then create a concrete implementation of that strategy object that collaberates with the Window's viewmodel to perform whatever task it needs to. In this case the Window's viewmodel might even implement the strategy interface itself.
Other instances of the UserControl in other scenarios can then be initialised with other concrete implementations of the strategy object that perform the same required task, but possibly in very different ways.