一个模型实体，多个页面 ->多个视图？多个视图模型？

Question

由于屏幕空间有限，我将使用多个页面（连续显示 - 思考向导）捕获单个实体的用户输入。在我的模型中，我希望将此实体建模为单个类是正确的。

在 MVVM 实现中，我假设最好的 MVVM 实践是将每个页面视为单独的视图。这是正确的吗？

关于每个页面是否拥有自己的 ViewModel 还是应该有一个被多个页面引用的 ViewModel 实例，对于最佳 MVVM 实践是否存在共识？

举例说明：

选项 1

Class A (X, Y, Z)
ViewModelA1 (X)
ViewModelA2 (Y)
ViewModelA3 (Z)
View1 captures ViewModelA1
View2 captures ViewModelA2
View3 captures ViewModelA3

选项 2

Class A (X, Y, Z)
ViewModelA (X, Y, Z)
View1 captures ViewModelA.X
View2 captures ViewModelA.Y
View3 captures ViewModelA.Z

Answer 1

“观”字说明了一切。这是数据的视图。 ViewModel 的工作是使来自模型的数据可呈现。需要对数据执行的任何操作都发生在视图模型中，以便视图可以显示它。

通常，您的视图与视图模型之间会存在一对一的关系，因为通常您只想以一种方式显示该数据。 （一个“视图”）
我偏离正常做法的地方（可能偏离 MVP 模式？）是，如果您想以多种不同的方式显示数据（例如您想要条形图、折线图或饼图）并且数据对于所有视图都是相同的，那么您只需要一个视图模型。这是 DRY 原则的一个例子。如果您有三个视图模型并且它们都相同，则使用一个视图模型。多个视图。一个视图模型。

Answer 2

我确信有人会以某种方式强烈争论。从我的角度来看，这完全取决于您需要重用哪些代码。构建 ViewModel 的方法有以视图为中心和以模型为中心的方法，但我认为任何一种方法都不总是正确的方法。

如果您发现您的 ViewModel 往往过于注重特定于 UI 的逻辑，那么良好的设计将倾向于在 View 和 ViewModel 之间建立 1:1 的关系，每个 ViewModel 包装多个 Model。这种方法的危险在于，您可能会花费大量代码来连接每个 ViewModel 中的数据并保持同步，并且需要在每个 ViewModel 中重复这种连接。呃。

然而，您也可能遇到这样的情况（就像我在当前项目中所做的那样），ViewModel 必须处理底层模型中的复杂关系，并且可以从多个端点（即用户或用户）更新各种模型实体。双工 WCF 服务）。在这种情况下，您会在每个 ViewModel 中花费大量时间来确保其数据与底层模型同步，并且在每个 ViewModel 中重新执行所有逻辑是愚蠢的。在这种情况下，我发现最简洁的方法是让 ViewModel 与模型进行或多或少 1:1 的映射，并在多个视图中重复使用。这种方法的缺点是，您最终可能会将来自各种不同视图的大量特定于 UI 的代码混合到同一个类中，这会导致测试和维护变得困难。 （是的，我知道 ViewModel 不应该与任何特定的 UI 紧密耦合，但是您最终仍然会得到很多代码，实际上是“当用户执行绑定到某个 UI 元素的命令时，我会执行该命令”。我假装什么都不知道，做另一件我假装我不知道的事情会导致出现一个对话框。”即使在这个抽象级别，编码到 ViewModel 中的逻辑也可能有所不同视图到视图。）

然后还有各种混合方法，这可能在现实场景中最有帮助。例如，您最终可能会在视图模型中使用继承层次结构，以便处理一个或多个基类中的通用连接，然后在继承链的下游类中添加特定于 UI 的部分。

无论如何，我对大多数 MVVM 文章的不满之一是，它们处理的场景过于简单化，无法反映现实世界中的复杂性。一旦您经过一位顾客 ->订单-> OrderDetail 之类的形式，我发现我读过的大多数建议都容易崩溃，而我只能自己寻找出路。

Answer 3

正如我所学到的（和实践的），关于 MVVM 的相关最佳实践：

• 每个页面/视图都有一个 ViewModel。

• ViewModel 应该只具有与使用它们的视图相关的字段/属性。

• ViewModel 可以根据需要从多个底层逻辑模型/类组合。

上述内容最终可能会产生更多模型，但随着时间的推移，它们会更容易使用，因为对单个 View/ViewModel 的更改不会影响其他视图或 ViewModel

这与您的第一个选项相匹配。

Answer 4

在 MVVM 实现中，我是
假设 MVVM 的最佳实践是
将每个页面视为一个单独的视图。
这是正确的吗？

是的，我会根据它的复杂程度来这样做。我认为 MVVM 对于大多数 WP7 应用程序来说只是一种杀伤力。

Answer 5

选项 1 是更适合使用的模型。

我不确定你的 X、Y 和 Z 是什么意思。

你应该简单地将模型的相同实例传递给每个 ViewModel

Class Model
{
  string X { get;set;}
  string Y { get;set;}
  int Z { get;set;}
}

Class MainViewModel
{
  // constructor
  ViewModel()
  {
    model = new Model()
    SubViewModel = new SubViewModel(model);
  }

  Model model {get;set;}
  SubViewModel sub { get;set;}

}

Class SubViewModel
{
  // ctor
  SubViewModel(Model model)
  {
    this.model = model;
  }

  Model model { get;set;}
}

MainViewModel 处理每个 SubViewModel 之间的导航，但它们都在查看模型的同一个实例，所以他们都有相同的数据。

Answer 6

在某些任务中，我可能有与单个 ViewModel 关联的多个模型以及该任务的多个视图。例如，创建带有分组、图像等的产品。以产品为中心。

我还有一些任务，其中使用多个视图模型，由任务通过多个视图驱动。例如，在应用程序中创建一个用户帐户，其中包含多个第三方帐户（例如 Facebook、Twitter 等），其中每个 3rd 方 API 都有自己的一组要求，但通过一系列步骤向用户显示为单个任务。专注于用户帐户。

MVVM 模式根据需要很灵活。定义任务，将其分解，然后决定最适合该任务的任务。

Answer 7

瞧，你问的是这个：
我有 1 M。
我有3个V。 （假设您最好创建 3 个 V）。

我应该有 1 个虚拟机还是 3 个虚拟机？ 换句话说你会问，VM概念在哪方面更接近？在 M 侧还是 V 侧？

根据我迄今为止对该模式的经验，VM 与 V 的关系远更为密切。

因此，您的问题的快速答案是：3 个 VM（选项 1）。选项 2 是思考该模式的错误方式。