我目前有一个使用EntityFramework的项目.我的解决方案基本上是这样的：
> UI项目(包含控制器和视图)
>模型项目(包含EntityFramework模型)
>服务项目(包含与Model Project通信的服务类,用于将模型项目中的实体提供给UI项目)
我的控制器将实体框架直接创建的实体传递给视图.
这很好,很简单.
在过去,我将创建单独的视图模型类,并从EntityFramework为这些视图模型创建的实体进行映射.但现在我正在努力看到这一点.
我目前正在帮助实现一个项目,该项目从实体框架生成的实体映射到视图模型.它实际上使用AutoMapper来做到这一点.
现在这一切看起来都是很多努力和代码,收益很少.
我在这里错过了什么吗？
解决方法
另外：请注意,在以下几段中,我只是专门提到视图模型.我将在本文末尾解决质量分配漏洞等问题.
原因1：为View层提供所需的数据,而不是其他任何内容
这是一个有点“纯粹”的目标 – 在真正的MVC应用程序中,视图层只能访问当前所需的数据,而不是其他任何内容.视图模型对象现在成为从视图层到控制器的规范：“这是我需要显示您请求的视图的数据.”为了遵守基本的MVC原则,您需要确保所有关于要显示的数据的决策都由控制器做出.
换句话说,如果要显示用户的名字和姓氏,用户名和图片,则不需要(或想要)为视图层提供一个对象,该对象还包含有关用户密码,角色的信息(或者,采取一些可能不那么敏感的属性,高度或中间名称).相反,您为视图提供具有名字,姓氏,用户名和图片属性的对象,视图仅决定如何呈现数据.这样,您就可以确定所呈现的数据的决定权保留在控制器层中.
原因2：避免使用ORM工具的跟踪功能出现问题
一些ORM工具 – 甚至一些返回常规对象1的工具 – 使用非常复杂的方法来跟踪从数据层获得的对象的变化,以便更容易地更改记录.例如,您可能从数据存储中获取一个对象,更改该实例上的某些属性,然后在其他位置调用save()方法,并在数据库中更新该对象.根据ORM工具,将ORM实体转发到视图层可以有任何后果,从性能问题(最坏情况：数据库连接保持打开)到不需要的效果(比如,视图层中的错误会更改属性)数据存储).要避免这些,请将实体重新映射到与您的ORM工具无关的“真正常规对象”,然后再将它们发送到应用程序管道中太远.查看模型是实现此目标的一种方式(众多方式).
请注意,这是否必要完全取决于您的ORM工具.我不知道实体框架的内部工作原理几乎已经足够知道你是否需要关心 – 但是在(非常)EF的早期版本中这是一个问题,至少在不使用Code-First方法时.
结论：你需要关心吗？
不,不一定.你可以在没有视图模型的情况下做得很好,在这种情况下,它们只是另一层抽象,它并没有真正为应用程序添加任何复杂性.这一切都归结为你的ORM工具对你的代码提出任何要求,以及你是否是“MVC纯粹主义者”.
旁注：但是质量分配漏洞呢？
Queti-Mporta已经是pointed out,质量分配漏洞可能是个问题.我同意这是一个严重的问题,但我不同意它是通过使用视图模型解决的.
对我来说,视图模型是从控制器到视图的数据传输对象,帮助控制器整理和汇总应该显示的数据.为了避免质量分配漏洞等问题,我通常使用编辑模型,它们与视图模型非常相似,但在另一个方向 – 即控制器.不是每个人都有这种区别 – 如果你做的话,我并不在乎.但是,使用这个词汇表时,我建议您在让用户更改数据时始终使用编辑模型,并且只有在帮助您时才使用视图模型.
1在.NET中通常称为“POCO”或Plain Old CLR Objects. Java在POJO(Plain Old Java Objects)中具有等价性,如果您能想到可用于面向对象编程的语言,那么该语言也具有等价性.
