asp.net-mvc - asp.net mvc-2 中一页上的强类型部分 View 是否应该有一个组合 View 模型？

Question

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

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

例如，我有一个显示个人资料的页面，但也有一个内联表单来添加快速联系人。这些实体中的每一个都已经拥有自己的 View 模型，即我有一个 ProfileViewModel 和一个 ContactViewModel。

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

谢谢!

Answer 1

如果两个部分 View 都需要已定义的 View 模型，则托管这些部分 View 的页面需要以某种方式提供 View 模型。很容易想象IEnumerable<ProfileViewModel>如何必须提供给包含页面，因为联系信息可能来自后端。是否 ContactViewModel实际上保存任何数据吗？如果没有，您也许可以在包含页面的 View 中当场创建它，并且只传递 IEnumerable<ProfileViewModel> 即可。到它。

否则，包含 View 需要接收 IEnumerable<ProfileViewModel>和一个 ContactViewModel 。我倾向于的选项确实是定义一个新的 View 模型，其中包含这两个值的数据成员。与通过 ViewData[] 传递这些值的替代方案相比，它的记录更好，并且允许进行更好的编译器类型检查。 .

您的问题隐含着创建 View 模型是一件苦差事的观念。如果 View 模型的定义仅反射(reflect)某些后端实体的定义，则分部 View 的情况可能确实如此。如果是这种情况，您可能需要考虑直接传递后端实体，而不是在 View 模型中复制其定义和内容。

最后， View 模型只是一个工具。如果它们能增加值(value)，就使用它们。一些应用程序通过使用不同的 View 模型类获得了清晰度、文档化和松散耦合的优势。其他应用程序(通常是较小的应用程序)的 yield 不足以值得付出这些开销。不实现 View 模型(或任何其他设计模式)本身并没有什么“不好的做法”。如果您有合理的理由支持它，那么您可以对这种设计选择感到放心。