ASP.NET MVC术语让我很困惑-为什么选择“ViewModel”?

该模型是数据的视图不可知表示。这个 看法 模型是特定于视图的数据表示:它是 模型 从一个给定的 看法 点。

考虑一个由原始数据点组成的模型;柱状图视图可能有一个由一组存储桶和从该数据中提取的总计组成的视图模型。

从逻辑上讲,它是模型的一个子集或转换——它可以使用视图特定的函数按需生成,模型作为它的唯一输入。

关于视图上的属性与属性包或自定义对象…我相信有人对此有强烈的感情,但就个人而言,我看不出有什么大的不同。您正在生成模型的视图特定表示并传递它 以某种方式 确切的机制似乎并不那么重要。

在我关于这个主题的阅读中,我遇到了许多关于开发人员为什么会或不想使用 视图模型 . 有些人甚至认为 ViewModel should never expose anything more than strings . 在这一点上,我的思想并没有那么极端。不过,我同意,向视图公开域/核心对象不是一个好主意。在经历了一些第一手经验之后,消除这种依赖感觉就更干净了。

但我不同意丹尼尔·鲁特所做的一切 a pretty good case for a ViewModel :

大多数MVC示例都直接使用 模型类,如Linq to SQL 或实体框架类。视觉 MVC的工作室布线甚至可以指导您 在这个概念中默认 “添加视图”代码生成,它允许 您可以根据 单个模型类。然而,在 现实世界中你经常需要更多的应用程序 而不仅仅是一个表的数据 构建一个页面。一些例子得到 通过填充辅助数据来解决这个问题 但这是一种更好的方法 这是为了创建一个“上卷”类 包含的属性 一切 您的视图将需要。这有 更多的好处 强类型,支持 智能感知,可测试,以及 准确定义视图需要什么。

Jeff Handley对 ViewModel pattern 他认为这可以与MVC结合使用。

编辑
我最近的想法与 Jimmy Bogard's 关于视图模型。在我尝试过的每一个实现都经历了相当多的痛苦之后 having one view model per view creates 更清洁的开发经验。

回复:为什么控制器不能填充视图上的属性?

因为在控制器操作执行时视图不存在。从您的操作返回actionResult背后的想法是,稍后处理管道中的某些内容将评估结果并确定最佳的操作过程(可能呈现视图,也可能选择与请求匹配的视图(如为移动设备创建的特殊视图))。

我在这里做了一个关于选择正确类型的模型对象的视图文章:将m放在MVC中 Part I , Part II , Part III .

是的,术语“视图模型”现在很流行,但它是在精神上,最初的MVC采用者的想法。

这实际上不是一个答案,但我强烈建议你观看斯科特·汉塞尔曼的MVC2基础视频。它解释了所有的事情,即使我在做了很多事情之前已经做了ASP.NET MVC。

它在这里: http://channel9.msdn.com/Blogs/matthijs/ASPNET-MVC-2-Basics-Introduction-by-Scott-Hanselman

之所以叫它是因为它是“为视图制作的模型”。我理解为什么术语的选择有点混乱。

如果您不希望将所有数据作为一个大哈希数组传递给视图,那么这是一种有用的方法。它为您提供了一个专用于UI的强类型类,它既不污染核心模型,也不污染视图。它还允许您封装UI逻辑——视图应该 kept dumb .