对 .net MVC 视图模型和模型感到困惑答案

【问题标题】：Confused about .net MVC View Models and Models对 .net MVC 视图模型和模型感到困惑
【发布时间】：2012-03-14 14:55:16
【问题描述】：

所以，我已经阅读了一些关于 .net 和 MVC 的内容。我记得读过一些建议在 MVC 中使用 ViewModels 的东西。这将有助于减少让视图与应由控制器控制的数据混淆的愿望。

我认为这就是 MVVM 模式所指的内容。显然，在看过之后，实现实际上完全取消了控制器。不完全是我想做的。

在我的情况下使用 ViewModel 仍然合法吗？是更好的做法还是只是不必要的工作？你会把你的 ViewModels 目录/命名空间放在哪里？在 Models 目录下？

模型了解 ViewModel 是否合法？例如，你有一个 Model 返回一个 ViewModel 给控制器？

【问题讨论】：

我在一个使用 jqgrid 的 asp.net mvc 项目中。 jqgrid 需要特定的请求和响应数据结构。所以我创建了特定的视图模型来使用 jqgrid。对于简单的输入数据（到控制器操作），例如简单的值类型、字典类型、IEnumerable 类型，asp.net mvc 通常可以理解如何“绑定”到这些数据。
想要添加对此的引用，但不确定它是否符合任何特定答案，所以我将其放在这里：freshbrewedcode.com/joshbush/2012/03/05/…

标签： asp.net-mvc mvvm

【解决方案1】：

ViewModel 在 MVC 项目中不是默认的。如果您认为将 View 耦合到模型“更容易”有好处，则需要添加它

http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.net-mvc-applications

ViewModel 的概念不仅仅适用于 ASP.NET MVC，因为您会在有关 MVC、MVP 和 MVVM 模式的文章和博客文章中看到整个 Web 中对 ViewModel 的引用。这些帖子和文章可以围绕任意数量的技术，例如 ASP.NET、Silverlight、WPF 或 MVC...本文将探讨 ViewModels 在 ASP.NET MVC 世界中的应用。

http://msdn.microsoft.com/en-us/magazine/ff798279.aspx

【讨论】：

那么一个模型可以返回一个视图模型给控制器吗？出于某种原因，我认为它应该保持无视查看数据，并且控制器应该是将模型数据发送到 ViewModel，然后将其传递给视图的控制器。

【解决方案2】：

模型和视图模型是不同的。不要将 ViewModel 与 MVVM 模式混淆。

使用视图模型可以使模型和视图之间的交互更加简单。有时，将其他模型对象作为成员，模型可能会过于复杂，而这些成员可能会将模型对象作为成员等。

通过使用视图模型，您可以很好地简化视图处理的内容。这也将过滤掉智能感知中可以看到的内容，因此如果开发模型的人与处理视图的人不同，那么创建一个简单的视图模型可以让那些只处理 UI 的人更容易。

【讨论】：

那么你会把 ViewModels 命名空间放在 Model 命名空间下吗？这是应该在其他地方的东西吗？
没关系，看你自己，在我的项目中我一般会创建一个ViewModel文件夹。
@Walt - 大多数重要的项目将它们的业务和数据层放在不同的项目中，这使得 MVC 中的 Models 文件夹严格用于查看模型。如果你不这样做，那么你可以很容易地创建一个 ViewModels 文件夹来创建一个分离。
没关系，我以前也是这样。现在我倾向于创建更多的文件夹，如“ViewModels”、“Infrastructure”，以及更多的项目，如“projectname.Data”、“projectname.Core”和“projectname.Test”等。明确命名的文件夹清楚地表明它们的用途生活就是。

【解决方案3】：

在我看来，设计模式不是死板的概念，而是可以帮助您更好地构建应用程序的指南。 Model-View-ViewModel(MVVM) 设计模式源于 WPF，其中有一个非常健壮的 Bata Binding 框架来促进该模式。这个想法是您的模型中有业务数据，但是由于经常有不属于模型的视图特定数据（即树控件中的当前选定项），因此您创建了包装模型的视图模型对象，但视图模型也包含视图特定的状态数据。因此，您的视图可以直接绑定到视图模型而不是模型对象，从而保持模型干净（易于测试、维护等）。

Asp.net MVC 的不同之处在于视图中的数据绑定远没有 WPF 中的强大。在 WPF 中，您实际上可以通过数据绑定实现大部分 GUI 和模型数据交互，这使得视图模型非常有用。但是在 Asp.net MVC 中，您的控制器旨在处理此问题，并且由于数据绑定几乎不存在，我只是看不到在 Asp.net MVC 中围绕模型对象使用视图模型包装器的价值。

【讨论】：

您可能看不到值，但它就在那里。一方面，如果您通过数据注释使用 ASP.NET MVC 的内置验证，那么拥有一个用验证属性装饰的单独视图模型会更干净，而不是污染您的域对象。此外，您可以根据特定的视图要求定制视图模型，有点像视图的 DTO。
@Chris - 你认为实体级安全实现属于视图模型层而不是域模型吗？目前我正在考虑为我的每个实体添加安全 ID 字段，但它似乎“污染”了我的域（因为如果我使用不同的安全提供程序或框架，我可能需要更改我的域实体中的所有这些安全特定字段。
@Chris - 我想知道 ViewModel/Model 问题，因为在 .Net 中，至少，您可以将 ViewModel/Model 作为控制器中操作方法的参数。然后 .Net 自动填充来自表单提交或常规请求的值。如果您使用 ViewModel，则每次都必须执行额外的步骤才能将数据从 ViewModel 获取到您的模型中。另一方面，您的操作方法可能需要由多个模型表示的数据，因此 ViewModel 在这种情况下非常有用。
@Walt - 将视图模型映射到模型的问题是发明 AutoMapper 之类的东西的原因。如果您在操作方法参数中传递域模型对象，则表单属性与视图模型属性的自动绑定也适用于 ASP.NET MVC，只要域对象属性与表单字段名称对齐，但同样，您将复杂的域细节重新暴露给视图，这可能是不必要的。再次澄清一下，我通常认为 ViewModel 只不过是视图的 DTO 对象，可能包含一些表示层细节）。
@dan_l，我不确定您的代码的结构，但如果您担心以后更改提供程序，那么您的安全特定字段似乎是进一步抽象的完美候选者。您也许可以创建一个附加到每个对象的 ISecurityInfo 实现，并拥有一个执行必要安全检查的 ISecurityProvider 实现。如果您以后需要更改框架或安全提供程序，那么您可以轻松地这样做。