2

I am trying to wrap my head around MVVM and "models should not have behaviour". If my getter depends on an environment variable,

  • should it be in the model or viewmodel?
  • Does it make a difference if that getter is specific to one viewmodel vs many?

Also, I have complex setters that might have side-effects and logic. Does that automatically mean they belong into a viewmodel?

Updated: Some sources on this:

Models ... are not responsible for getting data, saving data, ...

Separate your User Interface concerns (View) from your Business objects and behaviors (View Model) and from your data/persistence layer (Model)

model ... holds the information, but not behaviors

Based on these I'm looking for some guidance for how to separate logic between model and viewmodel.

  • Where does the idea that the model should not have behaviour come from? – Jules Aug 23 '15 at 16:36
  • see updated question. – bebbi Aug 23 '15 at 19:15
-3

Your model classes should be simple and only store the data you wish to model for your application. You should avoid having any complicated methods or business logic in your model classes. I usually have constructors and basic properties (i.e. public getters, private setters) in my model classes and that tends to suffice.

Your view model classes should contain business logic and anything else required to facilitate presenting the data in your model classes in the corresponding views. View model classes can also access other required dependencies, such as environment variables. If you find that several view model classes require access to environment variables, you may want to introduce a separate class that accesses environment variables and then include this class as a dependency in your view model classes, preferably using dependency injection.

  • 1
    You might want to create a base view model class that these other view model classes will subclass and include a protected method in the base class that has this 'complex' functionality. – Bernard Aug 24 '15 at 17:26
  • 2
    Model classes aren't meant to be anemic and definitely shall contain business logic, that's why they're the model in the first place. View models contain the logic for your views, which is a part of your overall application logic. – rucamzu Dec 14 '15 at 11:26
  • 1
    @Bernard: by definition, the model layer contains your business logic. Whether the classes in there are bigger or smaller, more or less easily testable, it depends exclusively on your design and not on the amount of functionality you put in there. Any functionality that you don't include in the model, you're going to have to include it somewhere else and test it, so that's no solution. – rucamzu Feb 18 '16 at 15:03
  • 1
    The whole point of the MVVM pattern is to put the business logic in the model and the user interface logic in the viewmodel. These are two separate areas of concerns and should be segregated. – 17 of 26 Mar 24 '16 at 14:10
  • 1
    The "model" in Model-View-ViewModel means "Domain Model", not Data Model. – RubberDuck Jun 11 '16 at 15:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.