22

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.

Community
  • 1
  • 1
Kit
  • 20,354
  • 4
  • 60
  • 103
  • You know, it is actually possible to make commands a fourth party in MVVM, which know of both the View and the ViewModel, and can mediate between the two. It works very well when composing your VMs and commands in xaml... –  Aug 23 '11 at 17:09
  • @Will - this was kind of where I was headed. MVVM is somewhat new to me after a hiatus from server-side code and MVP client-side. I had thought the view would execute commands, commands would make service calls and manipulate view model, view model (through binding) would update the view. – Kit Aug 23 '11 at 17:19

4 Answers4

11

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.

Josh
  • 44,706
  • 7
  • 102
  • 124
7

I consider many of the current practices around MVVM violate SPR (at least). This is yet another situation where simply adding controllers back to MVVM would solve all the problems cleanly. I call it MVCVM :)

The pattern we are using successfully on all recent projects is to register controllers only, in modules, and initialise them at startup. The controllers are very light/slim and the only thing that needs to hang around for the life of the app listening for, or sending, messages. In their initialise methods they then register anything they need to own (views and viewmodels etc). This lightweight logic-only-in-memory pattern makes for slimmer apps too (e.g. better for WP7).

The problem with just using VMs, as you have found, is that eventually you hit cases where they need to know about views, or commands, or other stuff no self-respecting ViewModel should be involved with!

The basic rules we follow are:

  • Controllers make decisions based on events
  • Controllers fetch data and place it in appropriate View Model properties
  • Controllers set ICommand properties of View Models to intercept events
  • Controllers make views appear (if not implied elsewhere)
  • View Models are "dumb". The hold data for binding and nothing else
  • Views know they display a certain shape of data, but have no idea where it comes from

The last two points are the ones you should never break or separation of concerns goes out the window.

Simply adding controllers back into the MVVM mix seems to solve all the problems we have found. MVVM is a good thing, but why did they not include controllers? (but this is of course just my opinion) :)

iCollect.it Ltd
  • 92,391
  • 25
  • 181
  • 202
  • It really is feeling like view models do too much. If they are for manipulating the view, then they shouldn't embed commands that talk to... services. – Kit Aug 24 '11 at 12:37
  • 1
    What do you mean by "Controllers set ICommand...to intercept events"? – Kit Aug 24 '11 at 12:38
  • 3
    @Kit: ViewModels contain ICommand properties for binding to command events, but the action they point to (the code they run) should be determined/set by the controller. – iCollect.it Ltd Aug 24 '11 at 15:21
  • I also miss management or control of data-binding (incl. ICommand) in WPF-MVVM. I look upon WPF data-binding as effectively being the controller part, which we are not able to manage in a clear or clean way. Do you know of WPF examples where some kind of control of data-binding and ICommand is done? – Gerard Aug 17 '17 at 12:16
  • You don't need a "controller" (as in MVC), you can have a ViewModel inside another ViewModel, or even several viewmodels inside another ViewModel. – Luis Apr 20 '18 at 14:11
  • @Luis: That would miss the point of this answer: Complete separation of the logic from the models. If you put logic inside any viewmodel you have the same problems (nested or otherwise). – iCollect.it Ltd Apr 25 '18 at 14:17
  • @GoneCoding I'm talking about the MVVM design pattern, the one used in WPF, Xamarin and even in several JS frameworks like KnockOut or Vue. In MVVM the ViewModel is the controller in MVC. The command pattern is part of MVVM. I'm not talking about the ViewModels in ASP.MVC. – Luis Apr 25 '18 at 20:27
  • @GoneCoding Also, in MVVM the models are a separated object than the ViewModel, you are not putting logic in the model, you are putting loginc inside the ViewModel, that's the MVVM pattern idea. And as I said, you can have a "MainViewModel" acting as a "controller" (all the logic) and have another ViewModels with only properties, you don't need a "controller". – Luis Apr 25 '18 at 20:32
  • @Luis: So you are effectively using a model as a controller... so saying *you don't need a controller*, just because you hid it under a different name, is not a solid argument against separation of concerns, which was the point of my answer. Adding a controller *in addition to MVVM* gives much cleaner separation... Give it a try. You may change the way you test your code :) – iCollect.it Ltd Apr 26 '18 at 12:48
  • @GoneCoding give a try to ReactiveUI, IMHO you don't need a controller, just code the VMs in the right way. – Luis Apr 27 '18 at 16:34
  • @Luis: Just because there are alternatives does not invalidate the point I was making, but thanks for the downvote. Good to know that only your opinion matters :) – iCollect.it Ltd Apr 30 '18 at 17:10
6

No! MVVM does not violate SRP, (the programmer does, lol!)

There is no reason that using the MVVM pattern needs to ignore the SRP. MVVM does not mean that there is only one Model Class, one View-Model Class, and one View Class. Certainly, if you only had one View Class, you could only ever show one simple screen.

Those classes that are in the View tier, should be responsible for one thing; doing, deciding, or containing. A View can consist of several sub-views who's jobs are to do certain pieces of the users interractions. Consider a basic form, it has a display grid, items in the grid can be edited, and there is a "Save" button.

The main View would be a container for two other views; the datagrid (a user control, or something) and a command control. The datagrid then is responsible for choosing the right childview to render data in; in essense it's a container that databinds. The View to edit items is a child view of the datagrid, which is in-turn a child of the main View. Lastly the command control is a set of buttons (in this case a single one) who's single responsibility is to raise signals that commands have been issued by the user.

In this way the Edit View (used by the DataGrid) is agnostic about what uses it, and has one responsibility; Same with the command control. Likewise the DataGrid doesn't care about who uses it, only that it can contain the Edit View (child). Nice SRP there.

ViewModels to match the Views (and children) are also responsible for one thing. The Edit View Model is a container to which the Edit View Binds; it simply contains the data fields that can be displayed/edited. It doesn't care about anything but signalling when one of its properties change. The Command Button View Model is a class that does things. It's commands are bound to the buttons, and it will do work based on what the user clicks on. It will have to have access to other parts of the ViewModel(s) to do it's work.

The main page View Model is there to contain the other child views. It's sole responsibility is as an initializer, making all the required ViewModel instances, and passing constructor parameters to other ViewModel instances (say, the Command Button View Model so it knows where to get data for it's work)

It's natural to cram a whole bunch of functionality into a single ViewModel that a large View would bind to. But it doesn't have to be that way, and SRP can be maintained in MVVM.

The main goal of MVVM is to allow for testable design, the Model layer can be tested independantly, all classes in the Model can easily follow SRP. The ViewModel can be tested without the need of a view; it gets trickier to think SRP in the ViewModel, but it is certainly doable; just remember to break out your classes so they only have one concern. The View is bound to parter ViewModels, with any luck, your testing of the ViewModel makes snapping the View(s) on super easy. Remember you can have each View-let adhere to SRP to be part of a larger conglomerate View (container).

TL;DR? To answer your question directly, the View is a collection of classes that does not break the SRP. Thus, when the ViewModel is abstracted from the View(s) (View-First), they are also a collection of classes that adhere to good SRP.

EtherDragon
  • 2,679
  • 1
  • 18
  • 24
2

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 don't see why you've separated the first two items. Commands are part of the view.

As for the rest - you're right. In some cases. I've built applications where the tasks of value conversion and maintaining view state were sufficiently complex that it didn't make sense for a single view model class to do it all, and I broke them out into separate classes that interoperate with the VMs.

So?

Robert Rossney
  • 94,622
  • 24
  • 146
  • 218
  • *I* didn't separate those, but I do see your point. It seems the question of responsibility (as in "is it single or dual") seems to be around state modeling vs. commanding. I've seen conversion broken out in many implementations already, so I'll waive that one as a "decider". – Kit Aug 23 '11 at 18:48