我与自己辩论什么在它使用实体框架项目创建视图模型类的地步？
我现在有一个使用的EntityFramework项目。 我的解决方案基本上是结构是这样的：
我的控制器传递实体框架创建直奔视图的实体。
这是不错的，简单的。
在过去，我会创建单独的视图模型类，并从创建的EntityFramework这些视图模型实体映射。 但现在我挣扎明白这一点。
我目前正在帮助了上由实体框架生成，查看模型实体映射的项目。 实际上它使用AutoMapper做到这一点。
现在，这一切都似乎是一个很大的努力和代码非常小的收益。
我失去了一些东西在这里？
我能想到的一对夫妇的情况下的时候视图模型类的单独的层是一个很好的路要走，我会试图解释它们在一般的ORM工具和一般的MVC框架的条款 - 请注意，无论是这两种案件具体到ASP.NET MVC框架与实体框架（甚至也不是在.NET编程...）。
另外：请注意，在以下几个段落，我只是指专门查看模型。 我将在这篇文章的末尾ADRESS像质量分配漏洞问题。
这是一个很“纯粹”的目标 - 在一个真正的MVC应用程序，视图层只需要数据访问，它需要的时刻，而不是其他。 视图模型对象现在成为从视图层到控制器的规格 ：“这就是我要告诉你所请求的视图中的数据。” 为了坚持的基本原则，MVC，要确保在什么样的数据显示所有的决定都是由控制器制造。
换句话说，如果你想显示用户的姓和名，用户名和图片，你不需要（或希望）给视图层的对象，也有关于用户的密码，角色信息（或者，以采取一些属性可能不那么敏感，高度或中间名）。 相反，你给视图与姓，名，用户名和图片属性的对象，并认为只有决定如何呈现这些数据。 这样一来，你肯定是在什么样的数据决定呈现停留在控制层。
有些ORM工具-甚至有的那些返回规则物体1 -使用了相当复杂的方法来跟踪你的数据层获取对象的变化，为了使更改的记录更容易。 举例来说，你可以从你的数据存储中获取一个对象，该实例上改变一些属性，然后调用save()别处方法和对象在数据库中更新。 根据ORM工具，转发你的ORM，实体视图层可以有consequenses的任何范围，从性能问题（最糟糕的情况：数据库连接保持开放）有害的结果（比如说，在视图层的错误改变了性质数据存储）。 为了避免这些，把他们太远了应用程序管道前重新映射你的实体为“真有规则物体”，也没有关系到你的ORM工具。 查看模型是单向的（很多）来实现这一目标。
请注意，这是否必要或不完全依赖于你的ORM工具。 我不知道实体框架的内部运作几乎不够好，要知道，如果你有关心 - 但在（非常）EF早期的化身，这是一个问题，至少在不使用代码优先方法。
不，不一定。 你可以做无视图模型就好了，在这种情况下，他们是抽象的只是另一个层不真的，但复杂性添加任何东西到你的应用程序。 这一切都归结为wheter你的ORM工具使您的代码的任何要求，以及是否是一个“纯粹的MVC”。
雀替，Mporta已经指出的是质量分配漏洞可能是一个问题。 我同意这是一个严重的问题，但我不同意，它是通过使用视图模型来解决。
对我来说， 视图模型是从控制器到视图的数据传输对象，帮助控制器进行梳理和总结了应显示的数据。 为了避免这样质量分配漏洞问题，我通常使用的编辑模式 ，这是非常相似的，查看模型，但在另一个方向-即到控制器 。 不是每个人都使得这一区别 - 如果你做还是不做，我不很在乎。 但是使用这个词汇，我总是建议使用编辑模式，当你让用户改变你的数据，并使用视图模型，只有当它可以帮助你。
1在.NET通常被称为“POCO的”，或普通老式CLR对象。 Java有它的POJO的（普通Java对象）等价，如果你能想到可以在面向对象的编程中使用的语言，这种语言也有一个等价。
我个人比较喜欢使用的ViewModels因为它们可以包含特定于一个视图的信息。 但主要是作为一种方法，以防止直接在视图暴露我的实体。
附带的好处是避免质量分配漏洞 。 这些还存在于红宝石 。
我想看看这个问题，什么是视图模型在MVC这也解释了视图模型的目的。
没有什么错，直接从您的实体传递模型到视图，但是当你的模式是不适合你需要的数据精确匹配一个视图模型都可以使用。
