ViewBag VS模式，MVC.NET [英] ViewBag vs Model, in MVC.NET

问题描述

这是更通用的建筑问题：

我试图决定它是否确定为我的程序员使用ViewBags将数据传递到的意见已接受模型。

我个人的preference是避免ViewBags并建立包含所有数据可靠的模型视图要求：

方法1：

 模式A：
 - 员工名单
 - 可为空的整数，表示从列表中哪个项目是当前选定
 - 字符串的firstName（空，如果指数为null）
 - 字符串姓氏（空，如果指数为null）
 

方法二：

 模式A：
 - 员工名单ViewBag：
 -  ViewBag.Index（指示哪个项目从列表当前选择）
 -  ViewBag.FirstName
 -  ViewBag.LastName
 

谁能想到一个说法，为什么Approach2会比方法1好？

感谢您的输入

解决方案

在我看来，你应该的从不的使用 ViewBag 没有一个非常，非常好的理由。 布拉德·托马斯的回答指出了那些美好的原因之一，一个罕见的例子。

假设你对MVC Layouts\">布局的主（或<一个href=\"http://www.asp.net/mvc/videos/mvc-2/how-do-i/how-do-i-work-with-data-in-aspnet-mvc-partial-views\"相对=nofollow称号=：由整个网站和数十家强类型的意见指出，每个人都有自己的模型共享>局部视图）我如何在MVC局部视图数据的工作。你如何将数据传递到布局？一些策略我见过的：

1. 的布局属性添加到每个模型。

如果你没有太多的车型，或者它只是一个或两个额外的属性这可能是工作。这可以迅速成为维护的噩梦。

<醇开始=2>

让所有的车型，从保存的布局数据类继承。

我避免创建模型库类，但它有时是必要的。

<醇开始=3>

创建布局和通用模型基类的模型。

我见过MVC应用程序与任何观点可以利用几个布局。如果你的模型从基类继承，您可能需要为每个布局的基类。为了避免重复工作，我会为每一个布局的布局模式。然后，这样的事情可能会为你工作：

抽象类模型库＆LT; TLayout＆GT; {
    公共TLayout布局{搞定;组; }
}类模型：模型库＆LT; LayoutModel2＆GT; {这里/ *模式的东西* /}


<醇开始=4>

在将布局属性 ViewBag

有罕见的情况下，我可以想像，其中将在模型布局的信息是不正确的电话。看来pretty司空见惯的人使用他们的域模型作为自己的模型，你可能不希望与业务/域数据混合布局/视图的数据，例如。

---

如果您决定使用 ViewBag ，避免这种情况：

ViewBag.Title =我的页面
ViewBag.UserID = 123
ViewBag.UserName =管理员
ViewBag.UserDisplayName =管理员


有明显的潜在问题，如在不同的地方用不同的大小写（例如用户ID 而不是用户ID的）。不太明显的是，有人可能会不小心设置 ViewBag.UserID 到字符串或可空＆LT; INT＆GT ; ：

类SomeOtherClass {
    公共字符串用户名{获得;组; } //有人使用一个字符串...
}ViewBag.UserID = someOtherClassObj.UserID; //现在你就麻烦了。


所以，如果你必须使用 ViewBag ，我建议是这样的：

ViewBag.LayoutModel =新LayoutModel {用户名= User.ID，用户名= User.Name};


This is more of a generic architectural question:

I'm trying to decide if it's ok for my programmers to use "ViewBags" to pass data to views that already accept Models.

My personal preference is to avoid ViewBags and build Robust Models containing all the data the view requires:

Approach 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)

Approach 2:

MODEL A: 
- List of Employees

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

Can anyone think of an argument why Approach2 would be better than approach 1?

thanks for your input

解决方案

In my opinion, you should never use ViewBag without a very, very good reason. Brad Thomas' answer points out a rare example of one of those good reasons.

Say you have a master layout (or a partial view) shared by an entire website and dozens of strongly-typed Views that each have their own Model. How do you pass data to the layout? Some strategies I've seen:

1. Add the layout properties to every model.

If you don't have many models or it's just one or two extra properties this could work. This can quickly become a maintenance nightmare.

2. Have all your models inherit from a class that holds the layout data.

I avoid creating a ModelBase class, but it can be necessary sometimes.

3. Create a model for the layout and a generic model base class.

I've seen MVC apps with several layouts that any view could utilize. If your models inherit from a base class, you may need to have a base class for each layout. To avoid duplication of effort, I would create a layout model for each of the layouts. Then something like this might work for you:

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

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

4. Put layout properties in ViewBag.

There are rare situations I can imagine where putting the layout info in the model isn't the right call. It seems pretty commonplace for people to use their domain models as their model, and you may not want to mix layout/view data with the business/domain data, for example.

---

If you decide to use ViewBag, avoid this:

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

There are obvious potential problems, like using different capitalization in different places (e.g. UserId instead of UserID). Less obvious is that someone could accidentally set ViewBag.UserID to a string or Nullable<int>:

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

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

So if you must use ViewBag, I'd recommend something like this:

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

这篇关于ViewBag VS模式，MVC.NET的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！