为什么要使用视图模型？答案

【问题标题】：Why should I use view models?为什么要使用视图模型？
【发布时间】：2011-02-02 19:31:18
【问题描述】：

我是使用 ASP.NET MVC 开发 Web 应用程序的新手。事实上，无论技术如何，我对开发 Web 应用程序还是很陌生。

目前，我正在做一个项目，只是为了更好地了解 ASP.NET MVC 框架。在互联网上阅读 SO 和其他地方时，共识似乎是视图不应该直接处理业务对象（即实现业务逻辑并包含相关属性的对象）。相反，应该使用视图模型。但是，这会带来几个问题：

我的验证码应该放在哪里？
我需要添加代码以在业务对象和视图模型之间进行映射。

事实上，这看起来相当麻烦，而且我还没有真正看到有人正确解释为什么将业务对象传递给视图是一个坏主意。有人可以尝试解释一下（或指出一个好的解释）吗？

只是澄清一下；我不是在寻找有关如何处理上述视图模型的两个问题的示例，而只是解释为什么我应该使用视图模型。

【问题讨论】：

标签： asp.net-mvc viewmodel

【解决方案1】：

我的验证码放在哪里？

在视图模型上，您应该验证特定于应用程序的所有内容，例如日期应该采用 en-US 格式文化，....

我需要添加代码来映射业务对象和视图模型。

这就是为什么会有AutoMapper之类的工具。

当您在视图中直接使用域模型时会出现不同的问题：

视图对显示数据有特定要求（本地化/全球化），因此您要么最终在视图中使用意大利面条式代码，要么将此代码放在模型中，这样它们在其他应用程序中的可重用性会降低，因为您已经污染了它们带有特定的演示文稿
根据视图，您有不同的验证要求。让我们以添加和更新视图为例。在 Add 视图中，将不需要 Id 属性，也不需要它，因为您将插入一个新项目。在更新视图中，将需要 Id 属性，因为您将更新现有项目。如果没有视图模型，就很难处理那些特定的验证规则。
模型可能包含诸如IsAdmin 之类的属性，然后我将让您想象具有以下签名的控制器操作的含义：
```
[HttpPost]
public ActionResult CreateUser(BusinessObjectUser user) { ... } 
```
假设您通过不包含此属性隐藏底层表单。
业务模型不会经常更改，而 UI 可能会更频繁地更改。如果您的客户要求您将屏幕一分为二怎么办？您呈现信息的方式会发生变化，信息的格式也会发生变化。如果您将模型直接使用到视图中，那么每次更改时，视图的粗糙度都会变得越来越差。
如果 OP 使用了视图模型，我在 StackOverflow 的 asp.net-mvc 标记中回答的大约 60% 的问题不会被问到。

【讨论】：

感谢您的回复，但我并没有真正寻找有关如何处理这些问题的答案，而是寻找有关为什么我应该首先使用视图模型的解释。跨度>

【解决方案2】：

应该使用视图模型的三个原因：

原因 1：从视图中删除逻辑

原因二：安全

原因三：松散耦合

以下链接可能有用： http://www.codeproject.com/Articles/223547/Three-reasons-to-why-you-should-use-view-models

【讨论】：

【解决方案3】：

首先，允许视图直接访问 ASP.NET MVC 中的业务对象引入了一些额外的安全问题。当用户将值发回您的控制器时，ASP.NET MVC 会为您执行大量模型绑定。这可以使您面临各种攻击。通过在两者之间引入一个 View Model，可以确保只绑定你感兴趣的字段（因为 ViewModel 只会包含你关心的字段）。

至于其他问题：

我的验证码放在哪里？

我直接在我的 ViewModel 上使用 DataAnnotations。这允许我使用 ASP.NET MVC 中内置的模型验证架构。如果有任何验证，我会在我的控制器中处理它。

我需要添加代码来映射业务对象和视图模型。

没错。但是使用像AutoMapper 这样的东西可以大大减少你必须手工编写的样板代码的数量。

【讨论】：

AutoMapper 等工具有助于传输 tghs

【解决方案4】：

MVC 易于理解并且开销很小。但是那些使用模型-视图-控制器模式一段时间的人都知道它并不完美。差远了。 Model-View-ViewModel 模式提供了一个有趣的替代方案。

了解模型-视图-视图模型模式扩展了模型-视图-控制器模式很重要。如果您习惯于 MVC，这并不是一个戏剧性的范式转变。尽管 MVVM 的优点是微妙的，但它们是深刻的。

MVVM 与 MVC 相比有哪些优势？

更好地分离关注点
改进的可测试性
透明沟通

【讨论】：