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?

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