视图中的逻辑。

示例，显示一些文字：

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

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

使用数据触发器可以实现同样的效果。方式无关紧要，重点是：逻辑在视图中。必须彻底了解视图以理解两者：逻辑和实现。

viewmodel中的逻辑。

Xaml更容易：

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

和逻辑在viewmodel中：

public bool ShowText => TextAvailable && TextOk;

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

我个人更喜欢拥有简单的viewmodel和相当复杂的视图（xaml），充满了逻辑。最近我found a way让逻辑变得非常酷（没有额外的元素，更容易看到）。

我理解这两种方法都可以使用，因此问题基于意见，但我不想在我的软件中以疯狂的比例混合使用这两种方法。哪种方式更 clean 并且会被另一位MVVM程序员更好地接受？我应该更喜欢什么？为什么？

Answer 1

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

我想在纯MVVM场景中，ViewModel不了解它的View，也不了解它的数据将如何显示。在实践中，我认为这种情况很少遇到。大多数情况下，在编写ViewModel代码时，您将很好地了解其数据将如何显示和交互：换句话说，您将知道View将会是什么样的，以及它将如何表现

鉴于此，我认为在ViewModel中放置一些UI逻辑是一个问题。在视图中直接操纵UI元素的意义上我并不意味着什么;相反，在视图将绑定的ViewModel上具有属性，例如示例中的Boolean属性。逻辑越复杂，我就越有可能将它放在ViewModel中，因为虽然您可以通过可见性转换器和数据触发器在View中执行逻辑，但XAML可能会变得非常冗长。这并不是说我从不使用那些XAML功能，只是因为我通常会将它们用于更简单的逻辑。

在一天结束时，ViewModel支持View：基本上为它提供View的UI元素可以绑定的属性，从而提供两者可以通信的管道。根据您要实现的MVVM的纯度，您的选择是希望ViewModel支持View的程度，以及您希望隔离View的程度。

Answer 2

在我看来

2.View是一个viewmodel表示，viewmodel只需要最小的公开模型，因此逻辑应该是视图的一部分。

听起来更正确。

什么属于＆＃34;最低限度＆＃34;取决于业务逻辑要求（例如，必须显示警告，因为法律要求，此类属性属于VM）和设计师的天赋。所以业务逻辑不属于视图！

问题＆＃34;如果你有一个UIElementA作为UIElementB的DataContext，那么UIElementA是属于View还是ViewModel？＆＃34;显示，从视角来看，UIElementA UIElementB可以被视为VM，但UIElementB实际上不是VM。因此，作为DataContext的一些类（也不依赖于表示框架）可以并且应该放到视图层（OP强迫我重新考虑一些类的分配）。

总结：
ViewModel中较少依赖于UI的逻辑 更好，但在合理范围内。

MVVM - 视图逻辑：view vs viewmodel

视图中的逻辑。

viewmodel中的逻辑。

2 个答案: