MVVM - view logic: view vs viewmodel

Question

Where "should" view logic resides normally? In the view (including code behind) or in the viewmodel?

By logic I understand anything what is used to modify view (makes it dynamic), changing its elements properties: Visibility, IsEnabled, Content, etc. based on some conditions.

I am struggling between choosing correct statement:

1. ViewModel is responsible for all view "properties", if view needs some logic - this should be a job of viewmodel.

2. View is a viewmodel presentation, viewmodel only needs bare minimum to expose model, the logic thus should be a part of the view.

Logic in the view.

An example, to display some text:

<Grid Visibility="{Binding TextAvailable, Converter=...}">
    <TextBlock Text="{Binding Text}" Visibility="{Binding TextOk, Converter=...}" />
</Grid>

By looking at this xaml you know there are 2 properties in viewmodel: TextAvailable and TextOk, used to conditionally display Text.

Same can be achieved using data triggers. The way is irrelevant, the main point is: logic is in the view. One have to go through view thoroughly to understand both: the logic and implementation.

Logic in the viewmodel.

Xaml is easier:

<TextBlock Text="{Binding Text}" Visibility="{Binding ShowText, Converter=...}" />

and the logic is in the viewmodel:

public bool ShowText => TextAvailable && TextOk;

but this will require notification support, often subscribing/unsubscribing to events (using weak events if deterministic unsubscribing is complicated), to be able to tell the view OnPropertyChanged(nameof(ShowText)) if any relevant property is changed. Thus implementation is well spread among many methods/properties.

---

I personally prefer to have simple viewmodel and rather complicated view (xaml), full of logic. Recently I found a way to make logic looking really cool (no additional elements and easier to see).

I understand what both approaches can be used and question thus is rather opinion based, but I don't want to mix both approaches in crazy proportions in my software. Which way is more clean and would be better accepted by another MVVM programmer? What should I prefer and why?

Answer 1

I think the answer is to do whatever you feel comfortable with. I don't believe that one approach is objectively better than the other.

I guess in a pure MVVM scenario the ViewModel would have no knowledge of its View and no knowledge of how its data is going to be displayed. In practice I think this scenario is very rarely encountered. Most times when writing the ViewModel code you will have a fairly good idea of how its data is going to be displayed and interacted with: in other words, you will know what the View is going to look like, and how it is going to behave.

Given this, I don't think it's a problem to put some UI logic in the ViewModel. I don't mean in the sense of directly manipulating UI elements in the View; rather, having properties on the ViewModel that the View will bind to, such as the Boolean property in your example. The more complicated the logic is, the more likely I would be to place it in the ViewModel, as although you can do logic in the View via visibility converters and data triggers the XAML can get very long-winded. This is not to say that I never use those XAML features, just that I would typically use them for simpler logic.

At the end of the day, the ViewModel is there to support the View: essentially to provide it with properties that the UI elements of the View can bind to, thus providing the conduits through which the two can communicate. Your choice, based on the purity of the MVVM you want to implement, is how much you want to let the ViewModel support the View, and how much you want the View to be isolated.

Answer 2

In my opinion

2.View is a viewmodel presentation, viewmodel only needs bare minimum to expose model, the logic thus should be a part of the view.

sounds more correct.

What belongs to "bare minimum" depends on business logic requirements(e.g. warning must be shown, because of law requirements, such property would belong to VM) and on flair of designer. So business logic does not belong to the view!

The question "If you have an UIElementA as DataContext for UIElementB, does UIElementA belong to View or ViewModel?" shows, that from point of view UIElementA UIElementB can be considered as VM but UIElementB is really not a VM.
So some classes(also not dependent on presentation framework) which serve as DataContext could and should be put to the view layer(the OP forced me to rethink allocation of some classes).

To summarize:
The less UI-dependent logic in ViewModel the better, but within reasonable limits.