mvvm - 将 ICommand 添加到域模型对象是否合适？

Question

我正在为 Windows Store 应用程序应用 MVVM 模式(并在此过程中学习它)。

现在我倾向于在 View 和 ViewModel 之间建立 1:1 的对应关系，其中多个 ViewModel 依赖于同一个底层模型。

例如，假设我有一个实体“学生”。我有两种查看学生的方式:在全屏详细信息页面中或作为教室中的学生列表。这会产生以下 View/ViewModel 对:

StudentDetailsView/StudentDetailsViewModel

StudentListItemView/StudentListItemViewModel

目前我假设我的 ViewModel 将直接公开模型，并且我的 Xaml 将绑定(bind)到 ViewModel.Model.property-name(我意识到这是有争议的)。

假设我可以从任一 View (例如“毕业生”)对学生执行一些操作。我想在我的模型中具有毕业生行为(以避免贫血域模型)，并且我想避免依赖于同一模型的 ViewModel 之间的重复行为。

我的意图是有一个 ICommand(例如，一个 RelayCommand)，我可以在 View 中绑定(bind)一个毕业按钮。这是我的问题:

有什么理由不让 ICommand 成为 Model 类的属性吗？

基本上这将意味着类似以下内容(忽略对存储库的需要):

public class Student {
    public ICommand GraduateCommand { get { ... } }
    void Graduate() { ... }
}

这样，StudentDetailsView 和 StudentListItemsView 都可以拥有绑定(bind)到该命令的 Xaml(其中 DataContext 是 StudentViewModel，Model 是公共(public)属性):

<Button Command="{Binding Model.GraduateCommand}" />

显然我可以将 Student::Graduate() 公开，在两个 ViewModel 上创建重复的 GraduateCommands，并让执行委托(delegate)调用 Model.Graduate()。但是通过 ICommand 而不是方法公开类的行为会有什么缺点呢？

Answer 1

首先，在很多情况下，直接从 View 绑定(bind)到 Model 完全没问题, 如果可以实现 INotifyPropertyChanged模型上。它仍然是 MVVM。这可以防止 ViewModel 被大量“relay-directly-to-Model”代码弄乱。您仅在 VM 中包含 View 无法直接使用的内容(需要包装/非规范化/转换数据，或者模型属性不实现 INPC，或者您需要另一个验证层......)。

那说 , 命令是 View 和 ViewModel 之间通信的主要方式。

该命令可能有许多接收者(可能在不同的 ViewModel 上)。

Execute/CanExecute 模式通常不适合 VM 的上下文之外。

即使真正的东西是在模型的方法中完成的，命令也可能有一些逻辑，而不仅仅是委托(delegate)给模型(验证、与其他 VM 属性/方法的交互......)。

在测试您的虚拟机时，如果命令在虚拟机之外，您就无法对它们的行为进行 stub 。

由于这些原因， 命令不属于模型 .

如果您担心跨 VM 的代码重复，您可以创建一个 StudentViewModel来自 StudentDetailsViewModel和 StudentListItemViewModel会继承。 StudentViewModel将定义命令及其常见行为。