传递 ViewData 与创建新类
我在 StackOverflow 和其他地方看到了几篇文章，讨论了将来自多个实体的数据汇集到强类型视图中的各种方法，这些方法是使用 ViewData 对象或构造一个利用这两个实体的新自定义类。
在我看来，如果你代表某种新的混合实体，你会想要创建一个新类并按原样对待它。 但是，如果您传入的数据不一定是您正在使用的实体的一部分，但仍在模型中，例如下拉列表或其他 UI，我可以看到使用视图数据的原因元素。
我看到人们出于各种原因提倡其中一种，我想知道是否有任何规则规定何时使用其中一种而不是另一种？
I've seen several posts on StackOverflow and elsewhere discussing the various ways to bring together data from multiple entities into a strongly typed view, these being using the ViewData object or constructing a new custom class that utilizes both entities.
To me it seems that if you are representing some sort of new hybrid entity you would want to make a new class and treat it as such. However, I can see the reason for using view data if you're passing in data for things that aren't necessarily part of the entity you're working with, but are still in your model, such as drop down lists or other UI elements.
I see people advocating one or the other for various reasons and I was wondering is there any rule as to when to use one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
有一次我使用了类型化的 ViewDataModels。 我从来不需要将内容放入 ViewData 字典中并在视图中使用魔术字符串。 魔术弦感觉很脏并且很容易出错。
我通常做的是为所有控制器创建一个 ViewDataModel 类，即：
所有这些 *ViewDataModel 都扩展了一个公共 ViewDataModel 类，可用于将全局站点配置数据传递到视图。
我并不关心在 ViewDataModel 中放入什么。 如果我需要它，我会将其设为一个属性，并在需要时填充它，无论是某个 LINQ to SQL 类还是任意菜单配置类。
即使除了模型对象之外不需要额外的属性，稍后添加属性也比重新键入视图更容易。 我的很多 ViewDataModel 类都包含 1 个属性，但知道我可以添加更多属性而不需要重构任何内容是一种幸福。
我经常将 ASP.NET MVC 视为 ASP.NET MVVM 作为传输器 ViewDataModel 类，它将模型和垃圾（？）数据传输到视图，发挥着巨大的作用。
Once I went with typed ViewDataModels. I never ever had the need to put stuff in the ViewData Dictionary and work with magic strings in the View. Magic strings feels dirty and very error prone.
What I generally do is create a ViewDataModel class for all my controllers, that is:
All these *ViewDataModel's extend a common ViewDataModel class, useful to pass global site configuration data to the views.
I don't really care what I put in that ViewDataModel. If I need it I make it a property and fill it whenever needed whether that is some LINQ to SQL class or an arbitrary menu configuration class.
Even if you don't need extra properties other than a model object, it's easier to add a property later on than it is to retype a view. Quite a lot of my ViewDataModel classes consist of 1 property, but knowing I can add more without the need to refactor anything is a bliss.
I often think of ASP.NET MVC as ASP.NET MVVM as the transporter ViewDataModel classes that transport model and junk(?) data to the view play a huge role.
我不确定当除了要返回的模型之外什么都没有时创建 ViewModel 对象是否是一个真正好的做法。 它只是创建更多对象来为服务器进行垃圾收集。 我认为使用 ViewModel 很好，但仅在需要时才使用。 但我同意必须避免使用魔法字符串的事实。 它会创建较弱的代码，以后更难维护。
I'm not sure it's a really good practice to create ViewModel objects when there's nothing more than the model to return. It just create more objects to garbage collect for the server. I think it's good to use ViewModel but only when you need it. But I agree with the fact that magic strings must be avoided. It creates weaker code that it's harder to maintain later.