ViewModel 中内容的最佳实践
我想知道在 ViewModel 中放置诸如国家/地区列表之类的内容以绑定到下拉列表是好主意还是坏主意？例如在网站的注册页面上。
我的印象是 ViewModel 应该代表已填写表单的一个实例，但我认为我可能是错的，因为我看到其他人在他们的 ViewModel 中放入了列表之类的东西。
将其放在某个静态类中并直接从视图中调用不是更好吗？
像 CommonData.ListCountries();然后使用Lambda直接转换为视图中的SelectList项列表？
I am wondering if it is a good idea or bad, placing things like a List of countries in ViewModel, for binding to a drop down list? For example on a site's Registration page.
I was under the impression that a ViewModel is supposed to represent an instance of the filled out form, but I think I may be wrong as I have seen other people put things like lists in their ViewModel.
Would it not be better to put it in a static class somewhere and called directly from the View?
Like CommonData.ListCountries(); and then using Lambda to convert to SelectList item list in the view Directly?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您所意识到的，有多种方法可以实现您的目标。而 MVC 设计模式鼓励某些应用程序组织 如何组织模型、视图和控制器最终取决于偏好问题。
Scott Allen 讨论了他处理 ASP.NET MVC 下拉列表。 Scott 使用扩展方法将复杂类型的枚举转换为模型上的，而只会返回用户选择的值。然后他建议利用两个模型可以简化事情。
IEnumerable。然后，他描述了回发后 ASP.NET MVC 将不会返回他发送到视图的 IEnumerable这是对我所说的 ViewModel 和 FormModel 的合理描述。 ViewModel 将显示数据传送到视图，而 FormModel 用于将收集到的数据传送回控制器操作。进一步解释：
无论哪种情况，我都有一个硬性规则 永远不要为不同的视图重复使用模型。让您的模型与用于渲染它们的视图紧密结合，可以使您的视图更易于编写。您不必担心静态方法之类的事情，因为您的模型应该以易于渲染的形式将数据携带到其关联的视图。像 AutoMapper 这样的工具可以帮助将域对象“展平”到模型中以供显示。
如需其他阅读，请查看：ASP.NET MVC 术语让我困惑 - 为什么是“ViewModel”？
As you've realized there are a variety of ways to accomplish your goal. While the MVC design pattern encourages certain application organizations how you organize your models, views and controllers is ultimately a matter of preference.
Scott Allen discusses his preference for dealing with ASP.NET MVC drop down lists in a blog post. Scott uses an extension method to convert an enumerable of a complex type into an
IEnumerable<SelectListItem>on his model. He then describes that upon post back ASP.NET MVC will not be returning theIEnumerable<SelectListItem>he sent to the view, but only the value the user selected. He then suggests that utilizing two models can simplify things.This is a reasonable description of what I refer to as ViewModels and FormModels. A ViewModel carries the display data to the view and a FormModel is used for carrying collected data back to a controller action. To explain further:
In either case I have a hard rule to never reuse a model for a different view. Having your models closely aligned with the views used to render them makes your views easier to write. You don't have to worry about things like static methods because your models should be carrying data to their associated views in a form that is easy for them to render. Tools like AutoMapper can help "flatten" domain objects into models for display purposes.
For additional reading checkout: ASP.NET MVC terminology is tripping me up - why 'ViewModel'?
无论您的 View 需要什么数据，都将其放入 ViewModel 中。
在我看来，一旦你的视图经历了渲染过程，它就应该从它绑定的模型中获得所需的所有信息。
如果您开始使用辅助方法，那么视图在某种意义上就“回到了控制器”。扩展/帮助器方法适用于格式化等，但它们不应该通过模型调用。
不要忘记，您还拥有 ViewData（基本上是 HttpContext.Current.Items，适用于单个请求），这是一种轻量级存储机制，可用于跨部分视图共享数据（例如）。
Whatever data your View needs, put it in the ViewModel.
The way i see it, once your view is going through the rendering process, it should have all the info it needs from the Model it is bound to.
If you start to use helper methods, then the View is "going back to the controller" in a sense. Extension/helper methods are fine for formatting, etc, but they should not call through the model.
Don't forget, you also have ViewData (basically HttpContext.Current.Items, lives for single request), which is a lightweight storage mechanism that can be used to share data across partial views (for example).