视图逻辑:视图与视图模型

Question

“应该”视图逻辑通常驻留在哪里？在视图中(包括后面的代码)还是在视图模型中？

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

我在选择正确的声明之间挣扎着：

1. 如果视图需要某种逻辑，则viewmodel负责所有视图“属性”--这应该是视图模型的工作。
2. 视图是视图模型的表示形式，视图模型只需要最小限度地公开模型，因此逻辑应该是视图的一部分。

视图中的逻辑。

例如，要显示一些文本：

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

通过查看这个xaml，您知道视图模型中有两个属性：TextAvailable和TextOk，它们用于有条件地显示Text。

使用数据触发器也可以实现相同的功能。方法是不相关的，主要是：逻辑在视图中。我们必须彻底了解视图，才能理解两者:逻辑和implementation.。

视图模型中的逻辑。

Xaml更容易：

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

和逻辑在视图模型中

public bool ShowText => TextAvailable && TextOk;

但这将需要通知支持，通常是订阅/取消订阅事件(如果确定性取消订阅比较复杂，则使用弱事件)，以便能够在任何相关属性发生更改时通知视图OnPropertyChanged(nameof(ShowText))。因此，implementation在许多方法/属性中得到了很好的推广。

我个人更喜欢简单的视图模型和相当复杂的视图(xaml)，它充满了逻辑。最近我用found a way来使逻辑看起来很酷(没有额外的元素，更容易看到)。

我理解这两种方法可以使用什么，因此问题是基于意见的，但我不想在我的软件中把这两种方法混为一谈。哪一种方式更干净，更好地被另一个MVVM程序员所接受？我应该喜欢什么?为什么？

Answer 1

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

我猜在纯MVVM场景中，ViewModel将不了解它的视图，也不知道它的数据将如何显示。在实践中，我认为这种情况很少遇到。大多数情况下，在编写ViewModel代码时，您将很好地了解它的数据将如何显示和交互:换句话说，您将知道视图的外观和行为方式。

考虑到这一点，我不认为在ViewModel中添加一些UI逻辑是个问题。我的意思不是直接操作视图中的UI元素，而是在视图将绑定到的ViewModel上具有属性，例如示例中的布尔属性。逻辑越复杂，我就越有可能把它放在ViewModel中，因为尽管您可以通过可见性转换器和数据触发器在视图中执行逻辑，XAML可能会变得非常长。这并不是说我从不使用那些XAML特性，只是说我通常会将它们用于更简单的逻辑。

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

Answer 2

照我的想法

2.视图是视图模型的表示形式，视图模型只需要最少的时间就可以公开模型，因此逻辑应该是视图的一部分。

听起来更正确。

什么属于“最低限度”取决于业务逻辑需求(例如，必须显示警告，因为法律要求，这类属性属于VM)和设计者的天赋。所以业务逻辑不属于视图！

问题是“如果您将UIElementA作为DataContext for UIElementB，UIElementA属于视图还是ViewModel?”从角度来看，UIElementA UIElementB可以被认为是VM，但UIElementB实际上不是VM。

因此，一些类(也不依赖于表示框架)作为DataContext可以也应该放在视图层( OP迫使我重新考虑某些类的分配)。

总结：

较少依赖UI的逻辑在ViewModel中更好的，但在合理的范围内.