在理想的“hello world”中，应该将强类型模型传递回视图。
return View(MyModel);
如果事情变得棘手，我们可以创建一个
视图模型
return View(MyViewModel);
前任。
我的视图模型
我可以避免创建整个ViewModel
并部分使用ViewBag。
ViewBag.Foo = Foo;
return View(MyModel);
我意识到我会失去一些强类型的功能
（例如智能感知）
在我对该 ViewBag 的视图中。
这种方法是否草率？反对 MVC 代表什么？
如果是这样，ViewBag 的真正意义是什么？
我所知道的最有用的用例是带外数据，例如可能在每个页面上显示的消息。操作过滤器可以有条件地将该消息添加到 ViewBag。您可能不想修改每个视图模型类来保存不相关的消息，因为它可能是一个横切关注点。此类消息/小部件的一个示例是 Stack Overflow 中断公告。
我不建议使用 ViewBag代替视图模型。模型类方法具有典型的静态类型优势，但编写类的成本很低。
这是一个很好的问题，就个人而言，我真的不认为有任何意义——它所做的只是鼓励“懒惰”的编码。dynamic对象有它们的用途，但是，我不认为ViewBag是其中之一，我更愿意使用ViewData[]/ViewModel并在那里获得类型安全，尤其是当我知道我正在处理的类型时。
我还没有遇到过使用 ViewBag 而不是替代方案（正确结构化的视图模型）有益的场景。其他一些答案提到将其用于需要在每个页面上显示的数据。在这种情况下，您应该创建一个所有 ViewModel 都继承自的基本 ViewModel 类。我使用这个结构来存储登录的用户等。
在我看来，ViewBag 有一个目的：在编写最少代码的同时轻松快速地提供 ASP.NET MVC 的产品演示。这不是构建代码的最佳方式，但它销售产品。