asp.net mvc-2 中一页上的强类型部分视图是否应该有一个组合视图模型？
我有一个关于 asp.net mvc-2 强类型部分视图和视图模型的问题。
我只是想知道我是否可以（或应该）在一个页面上有两个强类型的部分视图，而不需要为该页面实现一个全新的视图模型。
例如，我有一个显示个人资料的页面，但也有一个内联表单来添加快速联系人。这些实体中的每一个都已经拥有自己的视图模型，即我有一个 ProfileViewModel 和一个 ContactViewModel。
因此，我的视图需要两个强类型分部视图，一个使用 ProfileViewModel 的 IEnumerable 列表，另一个使用 ContactViewModel。是否可能或希望避免创建第三个视图模型，即此页面的“IndexViewModel”，它包含 ProfileViewModel 和 ContactViewModel 的列表？不实现这个视图模型是不好的做法，还是更整洁，因为它会导致更少的视图模型？
谢谢！
I have a question about asp.net mvc-2 strongly typed partial views, and view models.
I was just wondering if I can (or should) have two strongly typed partial views on one page, without implementing a whole new view model for that page.
For example, I have a page that displays profiles, but also has an inline form to add a quick contact. Each of these entities already has it's own view model, i.e I have a ProfileViewModel and a ContactViewModel.
So my view needs two strongly typed partial views, one using an IEnumerable List of ProfileViewModels, and one using a ContactViewModel. Is it possible or desirable to avoid making a third view model, an 'IndexViewModel' for this page, which holds a list of ProfileViewModels and a ContactViewModel? Is not implementing this view model bad practice, or tidier as it results in less view models?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果两个部分视图都需要已定义的视图模型，则托管这些部分视图的页面需要以某种方式提供视图模型。很容易想象如何必须将
IEnumerable提供给包含页面，因为联系信息可能来自后端。ContactViewModel实际上保存任何数据吗？如果没有，您也许可以在包含页面的视图中当场创建它，并且只向其传递IEnumerable即可。否则，包含视图需要接收
IEnumerable和ContactViewModel。我倾向于的选项确实是定义一个新的视图模型，其中包含这两个值的数据成员。与通过 ViewData[] 传递这些值的替代方案相比，它的记录更好，并且允许更好的编译器类型检查。您的问题在某种程度上暗示了创建视图模型是一件苦差事的概念。如果视图模型的定义仅仅反映某些后端实体的定义，则分部视图的情况可能确实如此。如果是这种情况，您可能需要考虑直接传递后端实体，而不是在视图模型中复制其定义和内容。
最后，视图模型只是一个工具。如果它们能增加价值，就使用它们。一些应用程序通过使用不同的视图模型类获得了清晰度、文档和松散耦合的优势。其他应用程序（通常是较小的应用程序）的收益不足以值得付出这些开销。不实现视图模型（或任何其他设计模式）本身并没有什么“不好的做法”。如果您有合理的理由支持它，那么您可以对这种设计选择感到放心。
If both partial views require view models that are already defined, then the page that hosts those partials needs to supply the view models somehow. It is easy to imagine how an
IEnumerable<ProfileViewModel>must be supplied to the containing page, as the contact information likely arrives from the back end. Does theContactViewModelactually hold any data? If not, you might be able to create it on the spot in the containing page's view, and get away with passing only aIEnumerable<ProfileViewModel>to it.Otherwise, the containing view needs to receive both a
IEnumerable<ProfileViewModel>and aContactViewModel. The option I would lean towards is indeed defining a new view-model that has data members for those two values. It's somewhat better documented and allows for some better compiler type checking than the alternative of passing those values viaViewData[].Somewhat implied in your question is the notion that creating a view model is a chore. That may well indeed be the case for the partial views, if the view model's definition merely mirrors that of some back end entity. If that is the case, you might want to consider passing the back end entity directly instead of duplicating its definition and content in a view model.
Finally, view-models are just a tool. Use them if they add value. Some application gain clarity, documentation and loose-coupling advantages from using distinct view-model classes. Others, often smaller apps, don't gain enough to merit the overhead. There's nothing inherently 'bad practice' about not implementing view models (or any other design pattern, for that matter.) It's a design choice you can feel comfortable about if you have a reasonable argument in its favor.