asp.net-mvc – ViewBag vs Model,在MVC.NET中

这更像是一个通用的架构问题：

我试图决定我的程序员是否可以使用“ViewBags”将数据传递给已经接受模型的视图.

我个人的偏好是避免使用ViewBags并构建包含视图所需的所有数据的Robust Models：

方法1：

MODEL A: 
- List of Employees
- Nullable integer,indicating which item from the list is currently selected
- string firstName (empty if index is null)
- string lastname (empty if index is null)

方法2：

MODEL A: 
- List of Employees

ViewBag:
- ViewBag.Index (indicating which item from the list is currently selected)
- ViewBag.FirstName
- ViewBag.LastName

谁能想到一个争论为什么Approach2会比接近1更好？

感谢您的输入

解决方法

在我看来,如果没有非常好的理由,你绝不应该使用ViewBag. Brad Thomas’ answer指出了其中一个很好的理由的罕见例子.

假设你有一个由整个网站共享的主人layout(或partial view)和几十个强类型的视图,每个视图都有自己的模型.如何将数据传递给布局？我见过的一些策略：

>将布局属性添加到每个模型.

如果你没有很多模型,或者只有一两个额外的属性,这可能会有效.这很快就会成为维护的噩梦.

>让所有模型都从包含布局数据的类继承.

我避免创建一个ModelBase类,但有时可能是必要的.

>为布局和通用模型基类创建模型.

我见过MVC应用程序有几种布局,任何视图都可以使用.如果模型继承自基类,则可能需要为每个布局都有一个基类.为了避免重复工作,我将为每个布局创建一个布局模型.那么像这样的东西可能适合你：

abstract class ModelBase<TLayout> {
    public TLayout Layout { get; set; }
}

class Model : ModelBase<LayoutModel2> { /* model stuff here */ }

>在ViewBag中放置布局属性.

在极少数情况下我可以想象将布局信息放在模型中是不正确的调用.人们使用他们的域模型作为他们的模型似乎很平常,例如,您可能不希望将布局/视图数据与业务/域数据混合在一起.

如果您决定使用ViewBag,请避免这样做：

ViewBag.Title = "My page"
ViewBag.UserID = 123
ViewBag.UserName = "admin"
ViewBag.UserdisplayName = "Administrator"

存在明显的潜在问题,例如在不同的地方使用不同的大写(例如UserId而不是UserID).不太明显的是,有人可能会意外地将ViewBag.UserID设置为字符串或Nullable< int>：

class SomeOtherClass {
    public string UserID { get; set; } // someone uses a string...
}

ViewBag.UserID = someOtherClassObj.UserID; // Now you're in trouble.

因此,如果您必须使用ViewBag,我建议这样的事情：

ViewBag.LayoutModel = new LayoutModel { UserID = User.ID,UserName = User.Name };