ViewModel中的最佳实践

Question

我想知道这是一个好主意还是坏事，将类似国家列表的内容放在ViewModel中，以便绑定到下拉列表？例如，在网站的“注册”页面上。

我认为ViewModel应该代表填写表单的一个实例，但我认为我可能错了，因为我看到其他人在他们的ViewModel中放了像列表这样的东西。

将它放在某个静态类并直接从View中调用会不会更好？

与CommonData.ListCountries（）类似;然后使用Lambda直接转换为ViewList中的SelectList项目列表？

Answer 1

您已经意识到有多种方法可以实现您的目标。虽然MVC design pattern鼓励某些应用程序组织如何组织模型，但视图和控制器最终都是首选。

斯科特艾伦在一篇博客文章中讨论了他对处理ASP.NET MVC drop down lists的偏好。 Scott使用扩展方法将复杂类型的可枚举转换为模型上的IEnumerable<SelectListItem>。然后他描述了在回发后，ASP.NET MVC将不会返回他发送给视图的IEnumerable<SelectListItem>，而只返回用户选择的值。然后他建议使用两个模型可以简化事情。

这是我称之为ViewModels和FormModels的合理描述。 ViewModel将显示数据携带到视图，FormModel用于将收集的数据传送回控制器动作。进一步解释：

• ViewModels包含有助于呈现视图的数据。通过以这种方式组织我的ViewModel，我可以放置所有必要的信息，以将特定视图呈现到关联的模型中。这使我不必将ViewData用于任何不是真正临时的事情。
• FormModels用于收集用户输入。 FormModels（几乎）从不包含对其他复杂类型的引用，并且由基元，DateTime和字符串组成。

在任何一种情况下，我都有never reuse a model for a different view的硬规则。让模型与用于渲染它们的视图紧密对齐，使您的视图更容易编写。您不必担心静态方法之类的问题，因为您的模型应该以易于呈现的形式将数据传递到其关联的视图。像AutoMapper这样的工具可以帮助将域对象“扁平化”为模型以供显示。

有关其他阅读结帐：ASP.NET MVC terminology is tripping me up - why 'ViewModel'?

Answer 2

无论您的View需要什么数据，请将其放在ViewModel中。

我看到它的方式，一旦你的视图通过渲染过程，它应该从它所绑定的模型中获得所需的所有信息。

如果你开始使用辅助方法，那么View在某种意义上就是“回到控制器”。扩展/辅助方法适用于格式化等，但它们不应通过模型调用。

不要忘记，您还有ViewData（基本上是HttpContext.Current.Items，适用于单个请求），这是一种轻量级存储机制，可用于跨部分视图共享数据（例如）。