Should viewmodels contain static functional methods?

Question

If I have a Viewmodel designed to serve a purpose for a view -

Is it a good practice to add bunch of static methods to the viewmodel like - getting a list of items(viewmodel object) by consuming data from db? - updating the db using a property in the viewmodel?

I am using .NET MVC and feel like my viewmodels get cluttered with bunch of static functions and update methods.

The main reason behind creating viewmodel for the views was because the views started to contain a lot of functionalities for which info had to be fetched from all over the place. So instead, i decided to create a viewmodel to get the info from one place with one call.

Am I following a good coding pattern here? Or am I shooting in the dark?

Kurr

You should not put business logic in the Viewmodel for larger applications. Put it in its own layer. – Photoperiod

what about controller? – Quadriplegic

Answer 1

Is it a good practice to add bunch of static methods to the viewmodel

No, your viewmodel should simply be a POCO, containing as little (if not zero) business logic. A view models only job is to move data from the controller to the view.

Generally:

• The controller should obtain an instance of a model from somewhere
• this can be consumed by the view directly or if multiple models needs combining or extra information (not in a model per se) is required then a view model can be created.
• Ideally the view model should be created outside of the controller (keeping the controllers job clean), this can be achived simply by using a factory pattern

If you read the wikipedia page for the MVC pattern. You'll notice it is solely designed for the presentation of data, not business logic:

Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces.

so really none of the MVC objects (Model, View or controller) should contain business logic. The MVC patterns job is to render data (full stop)

---

That all said it is common to put simple business logic into the controller. Once sites get more complex, though, this should be avoided, for fear of creating a god object

Caye

Excellently put. However, I would say using a bit of initializer code (e.g. filling up SelectItemList or newing up your lists in general) should be acceptable in the ViewModel's constructor. Other than that, all business logic functions (i.e. doing something with the ViewModel) should be handled in a seperate service class. – Toler

I'd add that you might want to have a function or property that handles the presentation of information done in your viewmodel - eg: I have Item Size and Item Unit Of Measure, I might create a property string SizeDisplay { get { return string.Format("{0} {1}",ItemSize,ItemUOM); } } – Arteaga

@A.BurakErbora I would argue that what you describe isn't business logic. It's simply creating items for the UI. So that would be correct. Also bear in mind this is very much an idealised answer. – Caye

@CBauer I disagree. Having used both approaches I find that any calculated field ultimately becomes a burden down the line. If you have a POCO object it's much more flexible. Also everytime you access that field it has to do some processing. If you write it to a static property the processing only happens once and once only (micro optimisation I admit) – Caye

That's fine, but if your purpose as a view model is to be a layer between data and the view, and you're doing proper MVC pattern, then you would never put view logic in your model tier, which is what a static property or getter on your model would be. As for the micro optimization, yes, in any office I've worked at you'd have been laughed out of a code review for bringing that up as a potential source of inefficiency. – Arteaga

@Caye We developers usually add methods to ViewModel like onButtonTap, onRideSelected etc. Where would you put such interaction methods? – Sverdlovsk

Well those methods (admittedly only based on the name) sound like they should be in the controller. @MartinBerger – Caye

Answer 2

Am I following a good coding pattern here?

No, it's not a good pattern.

The main reason behind creating viewmodel for the views was because the views started to contain a lot of functionalities for which info had to be fetched from all over the place. So instead, i decided to create a viewmodel to get the info from one place with one call.

Store functionalities or any kind of logic is not the ViewModel's purpose. It should be just a transport mechanism that holds the data transported between the View and the Controller.

Consider move your "funcionalities" to Application, Service or another layer that makes sense for your application's architecture.

Benefice