什么时候可以使用 ViewData 而不是 ViewModels？答案

【问题标题】：When is it right to use ViewData instead of ViewModels?什么时候可以使用 ViewData 而不是 ViewModels？
【发布时间】：2011-03-26 06:54:23
【问题描述】：

假设您想要开发控制器以便使用 ViewModel 来包含您呈现的 View 的数据，那么所有数据是否应该包含在 ViewModel 中？什么情况下可以绕过 ViewModel？

我问的原因是我处于一些代码使用 ViewData 而一些正在使用 ViewModel 的位置。我想在团队中分发一组指南，说明何时使用 ViewData 是正确的，以及何时只是走捷径。我希望得到其他处理过这个问题的开发者的意见，以便我知道我的指导方针不仅仅是我有偏见。

【问题讨论】：

标签： asp.net-mvc viewmodel viewdata

【解决方案1】：

我个人从不使用 ViewData，一切都通过模型进行，除非我测试某些东西并且我很快需要能够看到视图上的值。强类型！

【讨论】：

我完全同意。魔术弦充其量是丑陋的，最坏的情况是麻烦。也就是说，我也使用 ViewData 来快速测试东西，但问题是当它最终成为永久解决方案时！
是的 - 100% 同意。如果它甚至可以被弃用，我更愿意。
@Pure.Krome：您当然可以使用我的帖子中描述的方法来模拟折旧。覆盖基本控制器中的 viewdata 属性并添加 [Obsolete()] 属性将给您相同的结果（本质上）。

【解决方案2】：

只是为了进一步 Fabian 的评论；您可以按照this article 中概述的步骤明确确保永远不会使用 viewdata。真的没有任何借口不在所有事情上都使用模型。

如果您别无选择，只能使用 ViewData（比如在现有项目中）；至少使用字符串常量来解析名称以避免使用“魔术字符串”。类似于：ViewData[ViewDataKeys.MyKey] = myvalue; 事实上，我将它用于任何需要“基于字符串”的东西（会话键、缓存键、VaryByCustom 输出缓存键等）。

【讨论】：

+1 - 我们在这里总是使用严格类型的视图模型，但确实使用视图数据进行少量附加“修剪”。这通常只发生在我们在多个地方重复使用的局部视图中。
@jim：同意，在某些情况下（如共享部分视图）这是不可避免的；因此，当您需要回退使用 ViewData 时，最好采取措施防止自己中弹 :)
字符串常量与魔术字符串是什么意思，为什么在共享局部视图中使用 ViewData 是不可避免的？
@Howiecamp：字符串常量至少是强类型；所以他们应该总是首选使用字符串文字来访问字典数据（这也为您提供了一个很好的“注册表”在一个固定位置的键）。关于 ViewData 的使用是“不可避免的”，这并不完全准确 - 但有时它是尝试创建某种基本“上帝”模型来处理所有情况的最佳选择。希望这有助于清理我的一些 cmets :)

【解决方案3】：

就 ASP.NET MVC 2 而言，ViewModel 模式是首选方法。该方法充分利用了编译时静态类型检查。这与compiling mvc views 相结合将使您的开发工作流程更快、更高效，因为在构建/编译时而不是运行时检测到错误。

【讨论】：

【解决方案4】：

随着视图变得越来越复杂，您可能希望考虑的一种方法是保留对输入字段的模型的使用，并使用 ViewData 来支持视图需要呈现的任何其他内容。

至少有几个论据可以支持这一点：

您有一个需要提供一些数据的母版页（例如，标题中的 StackOverflow 用户信息之类的内容）。应用站点范围的 ActionFilter 可以在每次操作后轻松地在 ViewData 中填充此信息。要将其放入模型中，需要站点中的所有其他模型然后从基础模型继承（这最初可能看起来不错，但很快就会变得复杂）。
在验证已发布的表单时，如果出现验证错误，您可能需要将模型（带有无效字段）重新绑定回视图并显示验证消息。这很好，因为输入字段中的数据会被回发并绑定到模型，但是您的视图需要重新填充的任何其他数据呢？（例如下拉列表值、信息消息等）这些将不会被回发，并且将这些重新填充到“围绕”回发输入值的模型上可能会变得混乱。使用..view 数据填充 ViewData 的方法通常更简单。

根据我的经验，我发现这种方法效果很好。

而且，在 MVC3 中，dynamic ViewModels 意味着不再有字符串索引！

【讨论】：