What to do with a parent-view command that manipulates a child view, and view modeling would be tedious or not required?

I know binding a view model to a view is ok, view models containing view models is ok, and views containing views is ok. I have a situation where it seems a sub-view needs to be bound to a view.

In particular, I have a case where a particular command's implementation do开发者_JAVA百科es not need to be in nor manipulate a view model in any way (and doesn't affect the underlying model-model either). I could put the command in a view model, bind it, and execute it, but that's a definite code smell preventing clean separation of the view model layer from the view layer.

The command is initiated from a parent view, but affects a child view. I can think of several ways to handle this.

• Add an event handler in the parent, somehow find the right child (not sure how to do that in Silverlight), and then do all the logic I need.
• Handle the event in the parent, but re-raise a different event (double dispatch). In the child, handle the second event, and do the logic.
• Bind the command to the parent and handle the logic in the command itself (or in the parent view's supplied delegate).
• Bind the command to the child view directly. In this case how would I specify the binding in the parent view's xaml to the right child view/control?
• Bind the command to the child view's view model as defined above.

What should I do?

The "No-Code-Behind" rule for MVVM is not meant to apply to code that is only related to the UI, such as setting focus, running animations, adjusting sizes, etc. So in your case, I'd put the code behind your Views, and just have one View reference the other.

Providing your Business Logic code stays in your ViewModels, and your Presentation/UI code stays behind your Views, you're good.