假设您想要开发控制器，以便使用 ViewModel 来包含所渲染视图的数据，那么所有数据都应该包含在 ViewModel 中吗？什么条件可以绕过 ViewModel？
我问的原因是我所处的位置有些代码使用 ViewData，有些代码使用 ViewModel。我想在团队中分发一组指导方针，说明何时正确使用 ViewData，何时只是走捷径。我希望得到其他处理过此问题的开发人员的意见，以便我知道我的指导方针不仅仅是我有偏见。
Assuming you wanted to develop your Controllers so that you use a ViewModel to contain data for the Views you render, should all data be contained within the ViewModel? What conditions would it be ok to bypass the ViewModel?
The reason I ask is I'm in a position where some of the code is using ViewData and some is using the ViewModel. I want to distribute a set of guidelines in the team on when it's right to use the ViewData, and when it's just taking shortcuts. I would like opinions from other developers who have dealt with this so that I know my guidelines aren't just me being biased.
发布评论
评论（4）
只是为了进一步阐述 Fabian 的评论；您可以按照 这篇文章。确实没有理由不使用模型来处理所有事情。
如果您别无选择只能使用 ViewData（例如在现有项目上）；至少使用字符串常量来解析名称以避免使用“魔术字符串”。大致如下： ViewData[ViewDataKeys.MyKey] = myvalue; 事实上，我将其用于任何需要“基于字符串”的内容（会话键、缓存键、VaryByCustom 输出缓存）键等）。
Just to further Fabian's comment; you can explicitly ensure viewdata is never used by following the steps outlined in this article. There's really no excuse not to use models for everything.
If you have no choice but to use ViewData (say on an existing project); at the very least use string constants to resolve the names to avoid using 'magic strings'. Something along the lines of:
ViewData[ViewDataKeys.MyKey] = myvalue;Infact, I use this for just about anything that needs to be "string-based" (Session Keys, Cache Keys, VaryByCustom output cache keys, etc).当视图变得更加复杂时，您可能希望考虑的一种方法是保留输入字段的模型的使用，并使用 ViewData 来支持视图需要呈现的任何其他内容。
至少有几个参数可以支持这一点：
您有一个母版页，需要提供一些数据（例如标题中的 StackOverflow 用户信息）。应用站点范围的 ActionFilter 可以轻松地在每次操作后在 ViewData 中填充此信息。要将其放入模型中，需要站点中的所有其他模型都从基本模型继承（这最初看起来可能不错，但它很快就会变得复杂）。
当您验证已发布的表单时，如果存在验证错误，您可能需要将模型（带有无效字段）重新绑定回视图并显示验证消息。这很好，因为输入字段中的数据被回发并将绑定到模型，但是您的视图需要重新填充的任何其他数据又如何呢？ （例如，下拉列表值、信息消息等）这些不会被回发，并且将它们重新填充到回发输入值“周围”的模型上可能会变得混乱。使用一种用..视图数据填充 ViewData 的方法通常更简单。
根据我的经验，我发现这种方法效果很好。
并且，在 MVC3 中，动态 ViewModel 意味着不再有字符串索引！
One approach you may wish to consider as your views become more complex, is to reserve the use of Models for input fields, and use ViewData to support anything else the View needs to render.
There are at least a couple of arguments to support this:
You have a master-page that requires some data to be present (e.g. something like the StackOverflow user information in the header). Applying a site-wide ActionFilter makes it easy to populate this information in ViewData after every action. To put it in model would require that every other Model in the site then inherit from a base Model (this may not seem bad initially, but it can become complicated quickly).
When you are validating a posted form, if there are validation errors you are probably going to want to rebind the model (with the invalid fields) back to the view and display validation messages. This is fine, as data in input fields is posted back and will be bound to the model, but what about any other data your view requires to be re-populated? (e.g. drop-down list values, information messages, etc) These will not be posted back, and it can become messy re-populating these onto the model "around" the posted-back input values. It is often simpler to have a method which populates the ViewData with the..view data.
In my experience I have found this approach works well.
And, in MVC3, the dynamic ViewModels means no more string-indexing!
我个人从不使用 ViewData，一切都通过模型进行，除非我测试某些东西并且我很快需要能够看到视图上的值。强类型！
I personally never use ViewData, everything goes through the Model, except when im testing something and i quickly need to be able to see the value on the view. Strongtyping!
就 ASP.NET MVC 2 而言，ViewModel 模式是首选方法。该方法充分利用了编译时静态类型检查。这与 结合使用编译 mvc 视图 将使您的开发工作流程更快、更高效，因为错误是在构建/编译时而不是运行时检测到的。
In terms of ASP.NET MVC 2, ViewModel pattern is the preferred approach. The approach takes full advantage of compile time static type checking. This in combination with compiling mvc views will make your development work-flow much faster and more productive since errors are detected during build/compile time as opposed to run time.