7

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

我最近遇到了将您的特定视图需要的数据片段（实际上，它已分配给ViewData）收集到一个名为 (NameOfView) ViewModel的新类中的约定。

收集这些数据使其与 View/Controller 交互提供的函数相关联，这让我觉得这是一个辅助结构，甚至是闭包机制（在“封装变量集合”的意义上）。

那么，既然它既不是视图也不是模型，为什么还要叫它“ViewModel”呢？

有没有人觉得这个名字很混乱？

编辑：将属性放到视图上以便控制器可以填充它们有什么问题（如在其他 MVC 框架中）？

4

5 回答 5

11

在我阅读这个主题时，我遇到了关于开发人员为什么会或不想使用ViewModel的各种争论。有些人甚至争辩说ViewModel不应该暴露任何东西，而不是字符串。在这一点上，我的想法并没有那么极端。但是，我同意将域/核心对象暴露给视图不是一个好主意。在一些第一手经验之后，消除这种依赖感觉会更干净。

虽然我不同意 Daniel Root 下面的所有内容，但它为ViewModel提供了一个很好的案例：

大多数 MVC 示例显示直接使用模型类，例如 LINQ-to-SQL 或实体框架类。用于 MVC 的 Visual Studio 布线甚至通过其默认的“添加视图”代码生成引导您进入此概念，这使您可以基于单个模型类快速生成视图。但是，在实际应用程序中，您通常需要的不仅仅是单个表的数据来构建页面。一些示例通过将辅助数据填充到 ViewData 中来解决此问题，但更好的方法是创建一个“汇总”类来包含 视图所需的所有属性。这具有更强类型、支持智能感知、可测试以及准确定义视图需求的额外好处。

Jeff Handley 很好地描述了ViewModel模式，他认为该模式可以与 MVC 结合使用。

编辑
我最近将我的想法与Jimmy Bogard关于视图模型的想法保持一致。在每次实现都经历了相当多的痛苦之后，我尝试让每个视图都有一个视图模型，从而创造了更清晰的开发体验。

于 2010-01-19T18:56:00.140 回答
10

该模型是数据的与视图无关的表示。视图模型是数据的特定视图表示：它是从给定视图点可能出现的模型。

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

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

关于视图上的属性与属性包或自定义对象......我敢肯定有人对此有强烈的感觉，但我个人认为没有太大的区别。您正在生成模型的特定于视图的表示并以某种方式传递它；确切的机制似乎并不那么重要。

于 2010-01-19T18:33:32.567 回答
1

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

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

我在这里写了一篇关于选择正确模型对象的帖子：将 M 放入 MVC第 I部分、第 II 部分、第 III 部分。

是的，“ViewModel”这个词现在很流行，但它是最初的 MVC 采用者所想的精神。

于 2010-01-25T02:39:07.390 回答
1

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

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

于 2010-10-31T21:40:52.040 回答
0

之所以这么叫，是因为它是“为视图而制作的模型”。我明白为什么术语的选择有点令人困惑。

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

于 2010-01-19T20:21:01.787 回答