Question

With current practices (at least with WPF and Silverlight) we see views bound via command bindings in the view model or we at least see view events handled in view models. This appears to be a violation of SRP because the view model doesn’t just model the view state, but responds to the view (user). Others have asked how to build view models without violating SRP or asked whether their implementations do so (this last is the controller in MVC, but roughly analogous).

So are current practices a violation of SRP? Or is "view model" really a collection of things that don’t violate SRP? To frame this a bit, it seems we need to know what is the single responsibility or if there are multiple responsibilities in the concept, are the individual responsibilities split out, conforming to SRP. I’m not sure.

Wikipedia’s definition of view model says

[T]he ViewModel is a “Model of the View” meaning it is an abstraction of the View that also serves in data binding between the View and the Model

This seems good enough for SRP, but then the entry later says (my emphasis added)

[The ViewModel] acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model

In a Prism blog post about the view model’s role, the author says (again, my emphasis)

What it boils down is that the view model is a composite of the following:

• an abstraction of the view
• commands
• value converters
• view state

I’m sure I’ve missed many definitions out there, but they seem to fall into these categories:

1. Single "vague" responsibility of modeling view state (so what do we
   mean by state)
2. Multiple responsibilities (view state, user interaction (i.e.
   commands))
3. A composite of single specific responsibilities (abstraction,
   state, interaction, conversion), thus having a single
   responsibility: "managing all that stuff".

If you’re curious, I "care" about this because (2) feels right, but seems counter to the prevailing implementations.

Answer 1

Single Responsibility as Martin defines it:

“THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.”

A ViewModel, as far as MVVM is concerned is really just a specialized implementation of a Presentation Model.

So while it could be argued that a Presentation Model should only represent the state of the UI, and that a Presenter/Controller should always broker the commands between the UI and the Presentation Model. If one follows this idea, with SRP dividing on State and Commands, then adding a command should not affect the class that represents state. Therefore MVVM would break SRP.

However…

I think this is grasping at straws. MVVM is a fairly specialized implementation used basically in WPF/Silverlight (and now browser clients).

Patterns are designed to make designs simpler where the alternative would be more cumbersome or less maintainable. Since MVVM is designed to take advantage of the extremely rich data binding capabilities of the presentation technologies, then it is a worthwhile trade off.