MVVM - 视图逻辑:视图与视图模型 [英] MVVM - view logic: view vs viewmodel

问题描述

应该"查看逻辑通常驻留在何处?在视图中(包括后面的代码)还是在视图模型中?

根据逻辑，我理解用于修改视图(使其动态)、更改其元素属性的任何内容:Visibility、IsEnabled、Content 等基于某些条件.

我在选择正确的陈述之间挣扎:

1. ViewModel 负责所有视图属性"，如果视图需要一些逻辑 - 这应该是视图模型的工作.

2. View 是一个 viewmodel 展示，viewmodel 只需要最低限度的暴露模型，因此逻辑应该是 view 的一部分.

视图中的逻辑.

一个例子，显示一些文本:

<TextBlock Text="{Binding Text}" Visibility="{Binding TextOk, Converter=...}"/></网格>

通过查看此 xaml，您知道 viewmodel 中有 2 个属性:TextAvailable 和 TextOk，用于有条件地显示 Text.

同样可以使用数据触发器来实现.方式无关紧要，重点是:逻辑在视图中.必须彻底查看视图才能理解:逻辑和实现.

视图模型中的逻辑.

Xaml 更简单:

和逻辑在视图模型中:

public bool ShowText =>TextAvailable &&文本确定；

但这需要通知支持，通常订阅/取消订阅事件(如果确定性取消订阅很复杂，则使用弱事件)，以便能够告诉视图 OnPropertyChanged(nameof(ShowText)) 如果任何相关属性发生更改.因此，实现在许多方法/属性中得到了很好的传播.

<小时>

我个人更喜欢简单的视图模型和相当复杂的视图(xaml)，充满逻辑.最近我找到了一种方法让逻辑看起来非常酷(没有额外的元素并且更容易看到).

我了解可以使用两种方法的内容，因此问题是基于意见的，但我不想在我的软件中以疯狂的比例混合使用这两种方法.哪种方式更干净并且更容易被其他 MVVM 程序员接受?我应该更喜欢什么?为什么?

解决方案

我认为答案是做任何你觉得舒服的事情.我不认为一种方法在客观上比另一种更好.

我猜在纯 MVVM 场景中，ViewModel 不知道它的 View，也不知道它的数据将如何显示.在实践中，我认为这种情况很少遇到.大多数情况下，在编写 ViewModel 代码时，您会非常清楚其数据将如何显示并与之交互:换句话说，您将知道 View 将是什么样子，以及它将如何表现.

鉴于此，我认为在 ViewModel 中放置一些 UI 逻辑不是问题.我的意思不是直接操作 View 中的 UI 元素；相反，在 ViewModel 上具有 View 将绑定到的属性，例如示例中的 Boolean 属性.逻辑越复杂，我就越有可能将它放在 ViewModel 中，尽管您可以通过可见性转换器和数据触发器在 View 中执行逻辑，但 XAML 可能会变得非常冗长.这并不是说我从不使用这些 XAML 功能，只是我通常会将它们用于更简单的逻辑.

归根结底，ViewModel 是为了支持 View:本质上是为它提供 View 的 UI 元素可以绑定到的属性，从而提供两者可以通信的管道.您的选择，基于您要实现的 MVVM 的纯度，是您希望让 ViewModel 支持该视图的程度，以及您希望该视图被隔离的程度.

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?

解决方案

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.

这篇关于MVVM - 视图逻辑:视图与视图模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！