ViewModels and rendering

Question

In several sample projects, I saw that ViewModels are used to convert data objects to strings, for use in a view.

ViewModel usually has a constructor that takes one parameter - a data object. Then the constructor will populate the various ViewModel properties (mostly strings and ints).

This prevents any complex logic from appearing in the view.

At first glance, this seems to me to be a good idea, since it more fully ensures the separation of representation from complex logic.

For example, let's say my view tried to display the “Size” property of a data object, the size of which was a number from 1 to 3, representing “Small / Medium / Large”.

Instead of having an if / switch statement in my view, I would just have “SizeString” or something similar in my ViewModel, and the if / switch statement went into the ViewModel constructor.

Does anyone disagree with this approach?

Would it be better to use some other approach, like helpers? And if so, why?

Answer 1

The goal of ViewModel is to represent (part of) a complex domain model, decomposed as primitives that can be displayed in one form or another.

This decomposition must take place somewhere. This may be a somewhat simple form of logic, such as my favorite example: converting a discrete value (OK, warning, error) into colors (green, yellow, red). This is the essence of what ViewModel does, so my default approach would be to encapsulate this logic in the ViewModel itself.

Consider an alternative: if the ViewModel is not implemented, then where? If you put the logic somewhere else, you get a ViewModel, which basically is a structure without logic. Allowing ViewModel to encapsulate the transformation / decomposition of a Domain object is consistent with the principle of single responsibility .

Although this is my default approach, I always know that logic may need to be reused for multiple ViewModels. In such cases, this may be a sign that the original ViewModel is indeed a complex ViewModel consisting of several subviews. In such cases, you can extract the general logic in a sub-ViewModel that encapsulates only that small part.

Answer 2

It converts everything to a string, because everything on the network is a string.

In principle, the presentation model should be in a ready-to-exit state. If the network was made only of numbers, we would turn everything into ints / decimals.

The whole point of view Model - formatting the data presented. In your case, the transfer size is small / medium / large. It’s not that separating logic from views that makes it valuable — it’s the ability to adapt your data to the Internet in one way, one place.

---

Reply to comment =>

Yes this good. I'm doing the same thing. But what needs to be said, I am not against this either. Because view and view models are the last in the dependency chain. I am quite pragmatic and completely against only situations where the developer uses the domain model as the presentation model, and the requirements for the presentation model conflict with the domain model (that is, when the developer adds new "domain objects" for representative purposes only).