As per the pattern, the ViewModel exposes Properties(with change notification) and Commands (to notify the VM of user actions) that the View binds to. The only communication that flows from the VM to the View is the property change notifications (so that the View can refresh itself with updated data).

In MVP or PresentationModel form of the pattern (if I'm not mistaken), the View implements a plain vanilla interface (consisting of methods, properties and/or events). With MVVM, it feels methods on the IView have been outlawed (along with IView itself).

One scenario I could think of was to set the focus to a certain control in the View. (When the user does ActionX, the focus should immediately be set to FieldY).

• In MVP, I'd write this as IView.ActivateField(NameConstant), which the presenter or PM would invoke.
• In MVVM, this seems to be a fringe case that needs a workaround / little bit of code-behind. The VM implements an ActiveField Property, which it sets to NameConstant. The view picks up the change notification event and in a code-behind event handler, activates the Name control.

Is the above just an exception to the norm? Or are there other such scenarios, where the VM needs to invoke a method on the View ?