ASP.NET MVC术语让我沮丧 - 为什么'ViewModel'？

Question

我是一名ASP.NET MVC新手，但之前使用过许多模型 - 视图 - 控制器框架。

我recently came across将您的特定视图所需的数据（实际上，它被分配给 ViewData ）收集到一个名为（NameOfView）的新类中的约定视图模型

收集这些数据，使其与视图/控制器交互提供的功能相关联，将我视为辅助结构，甚至是闭包机制（在“封装变量集合”中）。

那么为什么它被称为'ViewModel'，因为它既不是视图也不是模型？

有没有其他人觉得这个名字令人困惑？

编辑：将属性放到View上以便Controller可以填充它们（如在其他MVC框架中一样）有什么问题？

Answer 1

在我对这个主题的阅读中，我遇到了各种各样的争论，即开发人员为什么要或不想使用 ViewModel 。有些人甚至争辩说ViewModel should never expose anything more than strings。在这一点上，我的想法并不是那么极端。但是，我同意，将域/核心对象暴露给视图并不是一个好主意。经过一些亲身体验后，删除这种依赖感觉更干净。

虽然我不同意Daniel Root制作a pretty good case for a ViewModel的所有内容：

  

大多数MVC示例都显示直接使用   模型类，例如LINQ-to-SQL   或实体框架类。视觉   MVC的工作室布线甚至可以引导您   进入这个概念是默认的   “添加视图”代码生成，它允许   你很快就会根据a创建视图   单一模型课。但是，在   真实世界的应用程序，你经常需要更多   而不只是一个表的数据   构建一个页面。一些例子得到   通过填充辅助数据来解决这个问题   进入ViewData，但是更好的方法   这是为了创建一个“汇总”类   包含所有内容的属性   你的观点需要。这有   增加了更多的好处   强类型，支持   intellisense，可测试，和   准确定义视图需要的内容。

杰夫·汉德利（Jeff Handley）对ViewModel pattern给出了一个很好的描述，他认为Jimmy Bogard's可以与MVC一起使用。

修改
我最近的观点与having one view model per view creates的观点模型一致。在每次实施后都经历了相当多的痛苦之后，我尝试了{{3}}更清洁的开发经验。

Answer 2

该模型是数据的视图不可知表示。 view 模型是数据的视图特定表示：它是模型，因为它可能出现在给定的视图点。

考虑一个由原始数据点组成的模型;然后，直方图视图可能具有一个视图模型，该视图模型由一组桶和从该数据中提取的总数组成。

逻辑上，它是模型的子集或转换 - 它可以使用视图特定功能按需生成，并且模型作为其唯一输入。

关于视图与属性包或自定义对象的属性......我确信有人对此有强烈的感受，但我个人并不认为有很大的不同。您正在生成模型的特定于视图的表示，并以某种方式传递;确切的机制似乎并不那么重要。

Answer 3

Re：为什么控制器不能在视图上填充属性？

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

我在这里查看了关于选择正确类型的模型对象的帖子：将M放入MVC Part I，Part II，Part III。

是的，“ViewModel”一词现在很流行，但它符合原始MVC采用者的想法。

Answer 4

这实际上不是答案，但我强烈建议您观看Scott Hanselman的MVC2 Basics视频。它解释了一切，即使我已经完成了ASP.NET MVC，但它为我做了很多事情。

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

Answer 5

之所以称它是因为它是“为视图制作的模型”。我理解为什么术语的选择有点令人困惑。

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