在asp.net mvc-2中，一个页面上的强类型局部视图是否应该有一个组合视图模型？

Question

我有一个关于asp.net mvc-2强类型局部视图和视图模型的问题。

我只是想知道我是否可以(或者应该)在一个页面上有两个强类型的局部视图，而不是为该页面实现一个全新的视图模型。

例如，我有一个显示配置文件的页面，但也有一个用于添加快速联系人的内联表单。这些实体中的每一个都已经有了自己的视图模型，即我有一个ProfileViewModel和一个ContactViewModel。

因此，我的视图需要两个强类型的分部视图，一个使用ProfileViewModels的IEnumerable列表，另一个使用ContactViewModel。是否有可能或是否希望避免创建第三个视图模型，即此页面的“IndexViewModel”，它包含ProfileViewModels和ContactViewModel的列表？实现这个视图模型是不是不好的做法，或者更整洁，因为它导致更少的视图模型？

谢谢!

Answer 1

如果两个局部视图都需要已经定义的视图模型，那么托管这些局部视图的页面需要以某种方式提供视图模型。很容易想象如何将IEnumerable<ProfileViewModel>提供给包含页面，因为联系信息很可能是从后端到达的。ContactViewModel实际上包含任何数据吗？如果没有，您可以在包含页面的视图中就地创建它，只需向其传递一个IEnumerable<ProfileViewModel>即可。

否则，包含视图需要同时接收IEnumerable<ProfileViewModel>和ContactViewModel。我倾向于的选择实际上是定义一个新的视图模型，该模型具有这两个值的数据成员。与通过ViewData[]传递这些值相比，它有更好的文档记录，并且允许进行更好的编译器类型检查。

您的问题在某种程度上暗示了创建视图模型是一件苦差事的概念。如果视图模型的定义仅仅反映了一些后端实体的定义，那么对于部分视图来说可能确实是这种情况。如果是这种情况，您可能需要考虑直接传递后端实体，而不是在视图模型中复制其定义和内容。

最后，视图模型只是一个工具。如果它们增加了价值，就使用它们。一些应用程序通过使用不同的视图模型类获得了清晰度、文档化和松散耦合的优势。其他应用程序，通常是较小的应用程序，没有获得足够的收益来弥补开销。不实现视图模型(或任何其他设计模式，就这一点而言)本身并没有什么“坏习惯”。这是一种设计选择，如果你有合理的理由支持它，你就会觉得舒服。