我有一个关于asp.net mvc-2强类型部分视图和视图模型的问题。
我只是想知道我是否可以（或应该）在一个页面上有两个强类型的部分视图，而不为该页面实现一个全新的视图模型。
例如，我有一个显示配置文件的页面，但也有一个内联表单来添加快速联系人。这些实体中的每一个都已拥有自己的视图模型，即我有一个ProfileViewModel和一个ContactViewModel。
所以我的视图需要两个强类型的局部视图，一个使用IEnumerable List的ProfileViewModel，另一个使用ContactViewModel。是否可能或希望避免制作第三个视图模型，这个页面的'IndexViewModel'，它包含ProfileViewModel和ContactViewModel的列表？是不是实现了这个视图模型不好的做法，或者更整洁，因为它导致视图模型更少？
谢谢！
答案 0 :(得分：1)
如果两个局部视图都需要已定义的视图模型，那么托管这些局部视图的页面需要以某种方式提供视图模型。很容易想象如何将IEnumerable<ProfileViewModel>提供给包含页面，因为联系信息可能从后端到达。 ContactViewModel实际上是否包含任何数据？如果没有，您可以在包含页面的视图中当场创建它，并且仅向其传递IEnumerable<ProfileViewModel>。
否则，包含视图需要同时接收IEnumerable<ProfileViewModel>和ContactViewModel。我倾向于选择的是确定一个新的视图模型，它具有这两个值的数据成员。它有一些更好的文档记录，并允许一些更好的编译器类型检查，而不是通过ViewData[]传递这些值的替代方法。
你的问题中隐含的一点是，创建视图模型是一件苦差事。如果视图模型的定义仅仅反映某些后端实体的定义，那么部分视图的确可能就是这种情况。如果是这种情况，您可能需要考虑直接传递后端实体，而不是在视图模型中复制其定义和内容。
最后，视图模型只是一种工具。如果他们增加价值，使用它们。某些应用程序通过使用不同的视图模型类获得了清晰度，文档和松耦合优势。其他人，通常是较小的应用程序，没有足够的收益来支付开销。关于不实施视图模型（或任何其他设计模式，没有任何固有的“不良实践”）。如果你有一个合理的论据，那么这是一个你可以感到舒服的设计选择。