目前，我正在开发一个项目，只是为了更好地了解ASP.NET MVC框架。当在SO和互联网上的其他地方阅读时，共识似乎是，视图应该永远不直接处理业务对象(即实现业务逻辑和包含相关属性的对象)。相反，应该使用视图模型。然而，这引入了几个问题：
>我在哪里放我的验证码？
>我需要添加代码在业务对象和视图模型之间映射。
事实上，它似乎相当麻烦，我没有真正地看到任何人解释正确为什么这是一个坏主意传递业务对象的意见。有人可以尝试解释这个(或指向一个很好的解释)？
只是澄清;我不是在寻找如何处理上面的视图模型的两个问题的示例，但只是一个解释为什么我应该使用视图模型。
解决方法
Where do I put my validation code?
在视图模型上，您应该验证应用程序特定的一切，例如日期应该是en-US格式文化。
I need to add code to map between business objects and view models.
这就是为什么有工具，如AutoMapper。
当您在视图中直接使用域模型时，会出现不同的问题：
>视图具有显示数据(本地化/全球化)的特定要求，因此您可以在视图中使用意大利代码，或者将此代码放在模型上，以使它们在其他应用程序中的可重用性降低，因为您已经使用特定演示文稿
>您基于视图有不同的验证要求。让我们以添加和更新视图为例。在添加视图中，将不需要Id属性，并且不需要它，因为您将插入一个新项目。在更新视图中，Id属性是必需的，因为您将更新现有项目。在没有视图模型的情况下很难处理这些特定的验证规则。
>这些模型可能包含属性，如IsAdmin，然后我离开你的想象控制器动作的含义与以下签名：
[HttpPost]
public ActionResult CreateUser(BusinessObjectUser user) { ... }
假设您已通过不包括此属性从底层表单中隐藏此属性。>业务模型不会经常更改，而UI可能会更频繁地更改。如果您的客户要求您将屏幕拆分为两个？您呈现信息更改的方式和格式也改变。如果你直接在你的视图中使用你的模型，你的意见的可怕性变得越来越糟糕，每一个变化。>大约60％的问题我回答在ASP.NET-mvc标签中的StackOverflow不会被问过OP是否使用了视图模型。
