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.
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:
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: