为什么应该使用视图模型？

发布于 2024-10-16 00:18:48 字数 425 浏览 3 评论 0原文

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

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

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

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

故事还在继续 2024-10-23 00:18:49

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

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

原因二：安全

原因三：松散耦合

以下链接可能有用：
http://www.codeproject.com/Articles/ 223547/为什么应该使用视图模型的三个原因

回复收藏 0 原文

明天过后 2024-10-23 00:18:49

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

至于其他问题：

我的验证码应该放在哪里？

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

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

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

回复收藏 0 原文

许仙没带伞 2024-10-23 00:18:49

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

理解模型-视图-视图模型模式扩展了模型-视图-控制器模式非常重要。如果您习惯了 MVC，那么这并不是一个巨大的范式转变。尽管 MVVM 的优点很微妙，但意义深远。

MVVM 相对于 MVC 有哪些优势？

更好地分离关注点
提高可测试性
透明沟通

回复收藏 0 原文

黯然#的苍凉 2024-10-23 00:18:48

我的验证码应该放在哪里？

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

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

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

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

视图对显示数据（本地化/全球化）有特定的要求，因此您要么在视图中得到意大利面条式代码，要么将此代码放在模型上，以便它们在其他应用程序中变得不太可重用，因为您已经用特定的演示内容污染了它们。
您根据视图有不同的验证要求。我们以添加和更新视图为例。在“添加”视图中，不需要 Id 属性，因为您将插入一个新项目，所以不需要它。在更新视图中，Id 属性是必需的，因为您将更新现有项目。如果没有视图模型，将很难处理这些特定的验证规则。
模型可能包含诸如 IsAdmin 之类的属性，然后我将使用以下签名的控制器操作的含义留给您想象：
<前><代码>[HttpPost]
公共 ActionResult CreateUser(BusinessObjectUser 用户) { ... }
假设您已通过不包含此属性从基础表单中隐藏了该属性。
业务模型不会经常改变，而用户界面可能会更频繁地改变。如果您的客户要求您将屏幕一分为二怎么办？呈现信息的方式发生了变化，信息的格式也发生了变化。如果您直接在视图中使用模型，则随着每次更改，视图的混乱度会变得越来越差。
我在 StackOverflow 上的 asp.net-mvc 标签中回答的问题中，如果 OP 使用了视图模型，大约 60% 的问题就不会被问到。

Where do I put my validation code?

On the view models you should validate everything that's specific to the application like for example the date should be in en-US format culture, ....

I need to add code to map between business objects and view models.

That's why there are tools such as AutoMapper.

Different problems arise when you use directly your domain models in the views:

The views have specific requirements for displaying the data (localization/globalization) so you either end up with spaghetti code in your views or you put this code on your models so that they become less reusable in other applications because you have polluted them with specific presentation stuff
You have different validation requirements based on the view. Let's take for example the case of Add and Update views. In the Add view the Id property won't be needed and it won't be required because you will be inserting a new item. In the Update view the Id property would be required because you would be updating an existing item. It would be difficult to handle those specific validation rules without view models.
The models might contain properties such as IsAdmin and then I am leaving to your imagination the implication of a controller action with the following signature:
```
[HttpPost]
public ActionResult CreateUser(BusinessObjectUser user) { ... } 
```
assuming that you have hidden this property from the underlying form by not including it.
The business models don't change often whereas the UI could change more often. What if your customer asks you to split your screen in two? The way you present the information changes and the way it is formatted also change. If you use your models directly into the views the spaghetiness of your views becomes worse and worse with every change.
About 60% of the question I am answering on StackOverflow in the asp.net-mvc tag wouldn't have been asked if the OP have used a view model.

回复收藏 0 原文

~没有更多了~