Question

我是使用ASP.NET MVC开发Web应用程序的新手。事实上，无论技术如何，我都很擅长开发网络应用程序。

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

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

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

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

Answer 1

我在哪里放置验证码？

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

我需要添加代码以在业务对象和视图模型之间进行映射。

这就是AutoMapper等工具的原因。

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

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

Answer 2

为什么要使用View Models的三个原因：

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

原因二：安全性

原因三：松散耦合

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

Answer 3

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

至于其他问题：

我在哪里放置验证码？

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

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

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

Answer 4

MVC易于理解，并且开销很小。但是那些使用了Model-View-Controller模式一段时间的人知道它并不完美。差远了。 Model-View-ViewModel模式提供了一种有趣的选择。

重要的是要理解Model-View-ViewModel模式扩展了Model-View-Controller模式。如果您习惯了MVC，这并不是一个巨大的范式转变。即使MVVM的优点是微妙的，但它们是深远的。

MVVM与MVC相比有哪些优势？

更好地分离问题
可测试性提高
透明沟通

我为什么要使用视图模型？

4 个答案: