使用asp.net mvc 4和EntityFramework的ViewModes是Point

Question

我正在与自己辩论在使用Entity Framework的项目中创建ViewModel类的重点是什么？

我目前有一个使用EntityFramework的项目.我的解决方案基本上是这样的:

• UI项目(包含控制器和视图)
• 模型项目(包含EntityFramework模型)
• 服务项目(包含与Model Project通信的服务类,用于将模型项目中的实体提供给UI项目)

我的控制器将实体框架直接创建的实体传递给视图.

这很好,很简单.

在过去,我会创建单独的视图模型类,并从EntityFramework创建的实体映射到这些视图模型.但现在我正在努力看到这一点.

我目前正在帮助实现一个项目,该项目从实体框架生成的实体映射到视图模型.它实际上使用AutoMapper来做到这一点.

现在这一切似乎都需要付出很多努力和代码.

我在这里错过了什么吗？

Answer 1

我可以想到一些案例,当一个单独的视图模型类层是一个很好的方法时,我将尝试用一般的ORM工具和一般的MVC框架来解释它们 - 注意这两者都不是案例特定于带有实体框架的ASP.NET MVC框架(甚至在.NET中编程......).

另外:请注意,在以下几段中我只是特别提到了视图模型.我将在本文末尾解决质量分配漏洞等问题.

原因1:为View层提供所需的数据,而不是其他任何内容

这是一个有点"纯粹"的目标 - 在真正的MVC应用程序中,视图层只能访问目前所需的数据,而不是其他任何内容.视图模型对象现在成为从视图层到控制器的规范:"这是我需要显示您请求的视图的数据." 为了遵守基本的MVC原则,您需要确保所有关于要显示的数据的决策都由控制器做出.

换句话说,如果要显示用户的名字和姓氏,用户名和图片,则不需要(或想要)为视图层提供一个对象,该对象还包含有关用户密码,角色的信息(或者,采取一些可能不那么敏感的属性,高度或中间名称).相反,您为视图提供具有名字,姓氏,用户名和图片属性的对象,视图仅决定如何呈现数据.这样一来,你肯定是在决定哪些数据呈现停留在控制层.

原因2:避免使用ORM工具的跟踪功能出现问题

一些ORM工具 - 甚至一些返回常规对象^1的工具 - 使用非常复杂的方法来跟踪从数据层获得的对象的变化,以便更容易地更改记录.例如,您可能从数据存储中获取一个对象,更改该实例上的某些属性,然后在save()其他位置调用方法,并在数据库中更新该对象.根据ORM工具,将ORM实体转发到视图层可以有任何后果,从性能问题(最坏情况:数据库连接保持打开)到不需要的效果(比如,视图层中的错误会更改属性中的属性)数据存储).要避免这些,请将实体重新映射到与您的ORM工具无关的"真正的常规对象",然后再将它们发送到应用程序管道中太远.查看模型是实现此目标的一种方式(很多).

请注意,这是否有必要完全取决于您的ORM工具.我不知道实体框架的内部工作方式几乎已经足够知道你是否必须关心 - 但是在(非常)EF的早期版本中,这是一个问题,至少在不使用Code-First方法时.

结论:你需要关心吗？

不,不一定.你可以在没有视图模型的情况下做得很好,在这种情况下,它们只是另一层抽象,它并没有真正为应用程序添加任何复杂性.这一切都归结为你的ORM工具对你的代码提出任何要求,以及你是否是"MVC纯粹主义者".

旁注:但是质量分配漏洞呢？

Queti-Mporta已经指出,质量分配漏洞可能是一个问题.我同意这是一个严重的问题,但我不同意它是通过使用视图模型解决的.

对我来说,视图模型是从控制器到视图的数据传输对象,帮助控制器整理和汇总应该显示的数据.为了避免这样质量分配漏洞问题,我通常使用的编辑模式,这是非常相似的,查看模型,但在另一个方向-即到控制器.不是每个人都有这种区别 - 如果你做的话,我并不在乎.但是使用这个词汇表时,我建议您在让用户更改数据时始终使用编辑模型,并且只有在帮助您时才使用视图模型.

¹在.NET中通常称为"POCO",或简称旧CLR对象.Java在POJO(Plain Old Java Objects)中具有等价性,如果您能想到可用于面向对象编程的语言,那么该语言也具有等价性.

Answer 2

我个人喜欢使用ViewModels,因为它们可以包含特定于视图的信息.但主要是作为一种防止我的实体直接暴露在视图上的方法.

另一个好处是避免质量分配漏洞.这些也存在于Ruby中.