我对MVC4，EF5和 ASP.Net 相当陌生，我似乎无法在任何地方找到好的答案。
基本上，一切都应该通过视图模型完成，还是也可以合并视图包？
假设我有一个填充下拉列表的方法，并且我正在使用视图模型来表示视图的输出。
我可以使用Viewbag.DropDown = PopulateDropdown();还是合并会更好这进入视图模型，通过创建一个属性来保存PopulateDropdown();创建List<SelectListItem>
我知道ViewBag有多方便，但我还没有看到任何不使用它的充分理由？如果有人能给我更多的见解，那就太棒了。
基本上，一切都应该通过视图模型完成还是可以 还要加入Viewbag？
一切都应该在视图模型中完成。这就是视图模型。为满足视图要求而专门定义的类。不要将 ViewBag 与 ViewModel 混用。视图不再清楚信息来自哪里。要么只使用视图模型（我推荐的方法），要么只使用 ViewBags。但不要混合 2.
因此，在您的特定示例中，您的视图模型上将有一个类型为 IENumerable<SelectListItem> 的属性，在您的视图中，您将使用 Html.DropDownListFor 帮助程序的强类型版本绑定到模型：
@Html.DropDownListFor(x => x.ProductId, Model.Products)
显然，这些只是我的2美分。其他人会说混合使用ViewModels和ViewBags很好，我尊重他们的意见。
尽可能更喜欢 ViewModels，而不是 ViewBag。创建强类型视图。它使您的代码更简洁、更不脆弱、更不容易出错且易于维护。
ViewBags只是动态类型对象的字典，因此您将丢失：
- 编译时检查
- 充满信心地重构的能力（您将失去工具的支持）
- IDE 支持 - 例如导航到所有使用实例的能力
- 智能感知
对于奖励积分，广泛使用ViewBag也错过了使用MVC模式的重点
我的印象是，ViewBags是为了解决 asp.net 中的边缘问题而创建的，人们使用它们而不是像平台设计中最初打算的那样创建视图模型，这损害了他们的工作。
感谢为什么不大量使用ViewBag？