MVVM Light 中有两种 ViewModel 吗？

Question

许多人建议 WPF MVVM 开发人员不要将模型实例从 ViewModel 暴露给 View。要显示来自 Model 实例集合的信息，请将所有单个项目包装到 ViewModel 实例中，并将 ViewModel 集合公开给 View。

但是，在我看来，使用 MVVM Light 有两种 ViewModel：

• 与视图具有一对一关系的视图模型（例如MainWindowViewModel 或CustomerEditorViewModel）。假设只有一个MainWindow，那么就只有一个MainWindowViewModel。
• 与模型实例具有一对一关系的视图模型（例如CustomerViewModel）并且是模型实例的某种“机甲套装”，提供额外的功能，例如计算属性（例如来自@的Duration 987654328@ 和 EndTime)。一般公司有很多Customers，所以会有很多CustomerViewModels。

那么如何包装模型实例呢？

一个想法可能是创建派生自ViewModelBase 的包装类，但不使用ViewModelLocator 注册和实例化那些。我认为将两个单独的东西都称为 ViewModel 并不是一个好主意。

另一个想法可能是为第二种 ViewModel 使用一个新的基类，可能称为ModelInfo。在MainViewModel 的单个实例中，会有CustomerInfo 实例的集合，为Customer 模型数据提供附加功能。

我倾向于后者，但由于这似乎是使用 MVVM Light 的一个非常普遍的情况，我相信这个问题必须有一个通用的解决方案。

---

更新

我找到了an article by Laurent Bugnion，MVVM Light 的作者。 在他 2012 年的文章中，Bugnion 使用了两种不同的方法来初始化 ViewModel：

1. MainViewModel 注册到 ViewModelLocator 并且没有构造函数参数。因此它适用于依赖注入，可以通过ServiceLocator实例化。
2. FriendViewModel 未在 ViewModelLocator 中注册，其构造函数将 Model 实例作为参数。不能用ServiceLocator实例化，只能直接调用构造函数，传递模型实例。

这与我最初的问题中提到的区别非常一致，并且与如何包装模型实例的第一个想法一致。

Answer 1

这是我个人 7 年使用 MVVM 的经验。我说个人，因为你会在这个话题上发现很多矛盾，特别是当你参考官方MSDN definition

“在我看来有两种 ViewModel”

绝对不是，但这是一个常见的误解。 ViewModel 的第一个角色是成为 View 的可测试和可维护表示。正确的抽象是与您的视图而不是您的模型的一对一关系。

“许多人建议 WPF MVVM 开发人员不要公开模型实例 从 ViewModel 到 View。”

是的，它仍然是正确的，因为如果从OOP 的角度正确实现了您的模型，那么您将责任和业务逻辑放入其中。因此，您的 ViewModel 只是 INotifiedPropertyChanged，并包装了您想要从您的模型 公开的信息，以及您想要在您的模型中调用 in 的命令.

经典的解释（包括 MSDN 的解释）是不完整的，因为它假设您可以将一个 View 与一个 ViewModel 与一个 Model 对齐。因此，您的问题经常被忽略，因为在一个非常 CRUD 的系统中，您可以轻松地拥有这种一对一的关系。建立这种关系的另一种方法是使用CQRS，因为它允许您生成没有任何逻辑的模型，并直接与您的视图对齐以进行查询。

但正如您已经体验过的（如果您不使用 CRUD 或 CQRS 系统），在大多数经典实现中，您的 ViewModel 代表您的 View，但需要多个模型才能正常工作（这是非常自然的）。您必须在这些模型中放入尽可能多的业务逻辑。为了管理对不同模型的调用之间的流程，您添加了另一个抽象，可以称为服务。该服务应该代表一个需要使用多个模型的业务案例。

您可以这样想：您的 BusinessService 应该独立于基础架构工作。它不应该关心它是从 ViewModel 调用，还是从 Web App 中的 Controller 调用。它只是管理一些模型之间的流程以满足业务需求。

让我回顾一下：

• ViewModel 不应该有业务逻辑（但你已经明白了）

• ViewModel 是视图的抽象（而不是模型的抽象，即使在某些情况下您可以获得一对一的关系）

• 如果 ViewModel 需要多个模型来满足业务需求，请使用服务来管理不同模型之间的流程（根据定义，它变成了 BusinessService）

这是一篇带有代码示例的博客文章，以阐明我的观点： http://ouarzy.azurewebsites.net/2016/04/14/clarifying-mvvm-with-ddd/

希望对你有帮助。

Answer 2

据我所知，ViewModel 与 View 是一对一的关系。

在实践中，我发现我在没有视图的情况下使用 ViewModel——通常是在使用 ItemsSource 显示它们的集合时。如果它需要它，我将有一个 ItemsSource 视图 - 但如果它非常简单，我将只使用“父”视图。不确定这是否是最佳实践，但有一点需要绑定到模型的普通属性以外的其他东西，并且需要绑定到视图相关的属性，但是专用视图没有意义（在 DataGrid 行中例如，Row 可能是 ViewModel，但没有 View）。

这是我所说的一个例子。一个随机示例应用程序具有三个“主要”视图模型和视图：

更详细地说，这就是它们的结构。请注意，“EmployeeViewModel”没有“EmployeeView”。同样，这些“屏幕”视图模型根本没有任何模型，它们并不真正与数据对象相关联，也不需要模型：

如果我们只绑定到直接的数据项（并且没有其他与视图相关的逻辑，比如说一个“隐藏”属性来显示/隐藏我们的员工），那么我们就不需要 EmployeeViewModel，我们可以只绑定我们的EmployeeTrackerScreenViewModel 到许多 EmployeeModels。