ASP.NET MVC:在彼此内部嵌套ViewModels，反模式还是不？

Question

我有一个项目，其中ViewModels相互嵌套，因此它们本质上是域层次结构的字符串类型复制。例如，如果我们的域具有以下关系：

组织具有一对多的环境

环境中有一对多的机器

然后，将会有一个包含一对多EnvironmentViewModels的OrganizationViewModel，而EnvironmentViewModel本身也将拥有一对多MachineViewModels。然后，这种层次结构样式在整个应用程序中被重用，大约五个ViewModels中的一个属于这种类型。(例如，EnvironmentViewModel用于多个页面，MachineViewModel也用于其中许多页面，这取决于所查看的层次结构的级别...为了讨论的目的，我对此进行了简化，但层次结构比上面的3个稍大一点)。

现在，尽管我很想从上面下来谴责这种做法，但我还没有找到关于这种做法的太多信息。有没有人能告诉我关于既定实践的更多细节？分享趣闻轶事？

(我个人的偏见是，这些ViewModels不应该以这种方式相互嵌套，并且ViewModels实际上应该对应于视图，而不是域对象。我发现它在一些可维护性问题上相当混乱。但我想知道其他人的想法或经历。)

I've attached this question for reference but it describes nesting a domain object within a viewmodel, not viewmodels within each other.

Answer 1

视图模型应该是尽可能平坦的(尽管用于对多个相关属性进行逻辑分组的嵌套不可变对象对于整理目的来说是可以的)。

不要把它想成“视图模型应该对应于视图”，相反的想法是：“视图是视图模型数据的html表示”。

ViewModel是一个可怕的术语，因为它不是视图，也不是模型，而是资源的表示。

如果我这样做了：

`GET /User/1`

我希望返回一些表示用户1的数据。如果这是HTML格式，因为我发送了

`Accept: text/html`

那就这样吧。考虑一下视图模型是XML还是JSON。

尝试避免嵌套视图模型，因为您正在创建依赖链，只是复制属性，您实际上并没有违反DRY

Answer 2

我们过去曾关注过Josh Smith的文章Simplifying the WPF TreeView by Using the ViewModel Pattern。虽然它是WPF而不是MVC，但我相信这个概念仍然适用。我发现它是一种合理的机制，可以在每个上下文中区分显示的关注点，并允许更大的灵活性来重用。

HTH

Answer 3

我想说嵌套视图模型是很好的。我知道视图模型适用于一个特定的视图，但是如果不使用我的地址ViewModel，将它嵌套在各种其他视图模型中，似乎有点浪费。当然，这使得更新它变得容易得多，并且提供了一个很好的结构。

我确实试着让我的嵌套尽可能的平坦，尽管通常情况下，1级嵌套可以满足我所遇到的大多数场景。

我在这里回答了相关问题：Two models in one view in ASP MVC 3