【发布时间】:2021-10-09 10:28:17
【问题描述】:
我目前正在开发一个 UWP 应用程序,但我认为这个问题适用于任何具有 UI 的项目类型。我使用新的 Microsoft Toolkit MVVM 库为我的 UI 构建了一个视图模型。它具有以下属性:
private bool _isLoginAvailable = true;
public bool IsLoginAvailable
{
get => _isLoginAvailable;
set => SetProperty(ref _isLoginAvailable, value);
}
此外,我有一些业务方法作为参数需要多达 5-6 个这些属性。
在论坛上阅读,我发现视图模型中的业务逻辑不建议使用,因此,我提出了以下选项:
- 为方法创建一个新类,并使用视图模型作为参数:
SampleMethod(SampleViewModel vm)。然后,如果我在视图模型中创建此类的对象,我可以使用SampleMethod(this)。在这一点上,我真的看不出这个选项和在视图模型类中包含方法之间有什么区别。 - 我看到的第二个选项是将每个必需的参数添加到方法中,并在一个元组中返回每个参数:
SampleMethod(var1, var2, var3...) { return (var1, var2, var3...)}这对我来说似乎很麻烦。 - 我想到的第三个选项是使用 MVVM Toolkit 的消息传递功能。在这种情况下,我可以设置视图模型的构造函数来监听带有
Messenger.Register<SampleViewModel, Var1Message>(this, (r, m) => r.var1 = m.Value);的消息。然后,不同类中的方法可以使用Messenger.Send(new Var1Message(message)发送消息中的值。虽然这似乎是最好的选择,因为它可以与依赖注入一起轻松实现,但很快就会变得非常复杂,因为每个属性都需要一个新的密封类来描述消息。
这些选项中的任何一个是最佳做法,还是有我不知道的选项?
【问题讨论】:
-
“我看到不建议在视图模型中包含方法”。诶?作为一个没有意义的独立声明。 VM 可以包含任意数量的方法。你的意思是他们不应该包含 business 逻辑方法而不是视图逻辑?
-
您能否提供一个来源,说明为什么不建议在视图模型中包含方法?
-
将业务逻辑放在哪里是设计决策。有些人将控制器实例添加到 M-V-VM,有些人将所有逻辑放在 VM 中。一些模型。有些有一个额外的 BL 层。这是你自己的选择。
-
如果该方法适用于 VM 的属性,则无需传递任何内容。我会将方法留在拥有您使用的方法的同一 VM 类中。如果您将所有状态复制到下一个 VM 只是为了将方法与属性分开,那么您得到的只是代码膨胀。
-
@GazTheDestroyer,确实,我的意思是业务逻辑。
标签: c# mvvm uwp viewmodel windows-community-toolkit