title: Are current MVVM view model practices a violation of the Single Responsibility Principle?
body: <p>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 <a href="http://en.wikipedia.org/wiki/Single_responsibility_principle" rel="noreferrer">SRP</a> because the view model doesn't just model the view state, but responds to the view (user). Others have asked <a href="https://stackoverflow.com/q/596797/64348">how to build view models without violating SRP</a> or asked <a href="https://stackoverflow.com/q/2695204/64348">whether their implementations do so</a> (this last is the controller in MVC, but roughly analogous).</p>
  <p>So are current practices a violation of SRP? Or is &quot;view model&quot; 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 <em>concept</em>, are the individual responsibilities split out, conforming to SRP. I'm not sure.</p>
  <p><a href="http://en.wikipedia.org/wiki/Model_View_ViewModel" rel="noreferrer">Wikipedia's definition</a> of view model says</p>
  <blockquote>
  <p>[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</p>
  </blockquote>
  <p>This seems good enough for SRP, but then the entry later says (my emphasis added)</p>
  <blockquote>
  <p>[The ViewModel] acts as a data binder/converter that changes Model information into View information <strong>and passes commands from the View into the Model</strong></p>
  </blockquote>
  <p>In a <a href="http://www.developmentalmadness.com/archive/2009/10/28/mvvm-with-prism-101-ndash-part-5-view-model.aspx" rel="noreferrer">Prism blog post</a> about the view model's role, the author says (again, my emphasis)</p>
  <blockquote>
  <p>What it boils down is that the view model <strong>is a composite of the following</strong>:</p>
  <ul>
  <li>an abstraction of the view</li>
  <li>commands</li>
  <li>value converters</li>
  <li>view state</li>
  </ul>
  </blockquote>
  <p>I'm sure I've missed many definitions out there, but they seem to fall into these categories:</p>
  <ol>
  <li>Single &quot;vague&quot; responsibility of modeling view state (so what do we
  <em>mean</em> by state)</li>
  <li>Multiple responsibilities (view state, user interaction (i.e.
  commands))</li>
  <li>A composite of single specific responsibilities (abstraction,
  state, interaction,  conversion), thus having a single
  responsibility: &quot;managing all that stuff&quot;.</li>
  </ol>
  <p>If you're curious, I &quot;care&quot; about this because (2) feels right, but seems counter to the prevailing implementations.</p>