我有一个项目，其中ViewModels彼此嵌套，因此它们本质上是域层次结构的字符串类型复制。例如，如果我们的域具有以下关系：
组织有1到多个环境
环境有1到多台机器
然后会有一个OrganizationViewModel，其中包含一个或多个EnvironmentViewModel，而EnvironmentViewModel本身就有一个到多个MachineViewModel。然后，在整个应用程序中重用此样式的层次结构，其中包含此类型的大约五个ViewModel之一。 （例如，EnvironmentViewModel用于多个页面，MachineViewModel也适用于其中的许多页面，具体取决于正在查看的层次结构的级别...我已将其简化为讨论目的，但层次结构略大于上面的3个）。
现在，尽管我想从上面下来并谴责这种做法，但我还是找不到太多关于此的信息。有人能指出我有关既定做法的更多细节吗？轶事分享？
（我自己的偏见是这些ViewModel不应该以这种方式相互嵌套，而ViewModel实际上应该对应于Views，而不是域对象。我发现它有些可维护性问题非常混乱。但是我我想知道别人的想法或经历过。）
答案 0 :(得分：6)
viewmodel应尽可能平坦（尽管用于逻辑分组多个相关属性的嵌套不可变对象可用于整理目的）。
不要将其视为“视图模型应该与视图对应”，反过来想一想：“视图是视图模型数据的html表示”。
ViewModel是一个可怕的术语，因为它不是一个观点，它不是一个模型，它是一种资源的代表。
如果我这样做：
`GET /User/1`
我希望返回一些代表用户1的数据。如果是HTML格式，那是因为我发送了
`Accept: text/html`
尝试并避免在创建依赖关系链时嵌套视图模型，只复制属性，而不是真的违反DRY
答案 1 :(得分：0)
我们过去曾遵循Josh Smith的文章Simplifying the WPF TreeView by Using the ViewModel Pattern。虽然它是用WPF而不是MVC，但我相信这个概念仍然适用。我发现它是一种合理的机制，可以在每种情况下分离出显示的问题，并允许重复使用时具有更大的灵活性。
HTH
答案 2 :(得分：0)
我想说嵌套视图模型很好。我知道viewmodels是针对一个特定的视图但是通过将其嵌套在各种其他视图模型中而不使用我的Address ViewModel似乎有点浪费。当然可以让它更容易更新，并提供一个很好的结构。
我尽量保持尽可能平坦，但通常1级嵌套适合我发现的大多数场景。
相关问题我在这里回答：Two models in one view in ASP MVC 3
答案 3 :(得分：0)
ViewModels应该与UI概念相关联，而不一定是域概念。因此，在您的示例中，我可以想象一个显示组织详细信息和环境列表的屏幕;单击环境将显示一个详细信息屏幕，然后显示机器列表;然后单击其中一个将进入机器详细信息视图。
在该示例中，有两个不同的环境或机器视图，在列表中占据一行的摘要视图，以及占据屏幕更好部分的详细信息视图 - 每个视图都应该拥有它自己的视图视图模型。我可能会为此创建ViewModel：
OrganizationDetailsViewModel
----List of EnvironmentSummaryViewModels
EnvironmentDetailsViewModel
----List of MachineSummaryViewModels
MachineDetailsViewModel
根据您的UI的复杂程度，此嵌套可以更深入。让我们假设您有一个环境的小图形状态指示器，它查看状态并以某种颜色显示。您可以创建一个单独的EnvironmentStatusViewModel，然后将其嵌套在EnvironmentSummaryViewModel中，并且可能还嵌套在EnvironmentDetailsViewModel中。
答案 4 :(得分：0)
我仍然想知道优点和缺点。 它更快 - 或更简单的阅读？如果你有一个需要渲染所有信息的视图，那么急于提取所有内容以便在单个数据库中显示而不是多个懒惰的聊天连接？
在一个视图中，用户不希望看到包含所有相关“环境”和“机器”的“组织摘要”。如果没有别的，可能嵌套的项目的计数。 （不是环境和机器细节 - 这些不同的观点）
似乎倾向于构建视图以承担单一责任（查看机器（仅显示机器信息） - ＆gt;查看机器详细信息（仅显示机器详细信息）） 实现这一点很简单，但有时候视图功能不丰富，因为信息太少。