可能重复：
ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice?
在ASP.NET MVC中使用EF实体类作为视图模型是否可以？
如果viewmodel与EF实体类的90％相同怎么办？
假设我在Entity Framework模型中有一个Survey类。它90％匹配视图编辑所需的数据。 与视图模型应该具有的唯一区别 - 是要在其中使用的一个或多个属性（填充Survey对象所需的因为EF类不能直接映射到它的属性的表示方式（子复选框，无线电组等） 。））
你使用ViewData []传递它们吗？或者使用新的附加属性创建Survey类（SurveyViewModel）的副本（它应该能够从Survey复制数据并返回到它）？
修改 我也试图避免使用Survey作为SurveyViewModel属性。使用UpdateModel或使用默认绑定器更新某些Survey属性时看起来很奇怪，而其他（无法直接映射到实体）则使用控制器中的SurveViewModel自定义属性。
答案 0 :(得分：18)
我喜欢使用Jimmy Bogard's approach始终在视图和视图模型之间建立1：1的关系。换句话说，我不会将我的域模型（在本例中是您的EF实体）用作视图模型。如果你觉得你在两者之间进行了很多工作，你可以使用AutoMapper之类的东西为你做这项工作。
答案 1 :(得分：15)
有些人不喜欢将这些模型类一直传递到视图，特别是因为它们是与您当前使用的特定ORM相关联的类。这确实意味着您将数据框架紧密绑定到视图类型。
但是，我已经在几个简单的MVC应用程序中完成了这个，使用EF实体类型作为一些强类型视图的模型 - 它工作正常并且非常简单。有时简单的胜利，否则你可能会发现自己花了很多精力和代码来复制应用程序中几乎相同的模型类型之间的值，实际上你永远不会离开EF。
答案 2 :(得分：7)
即使它们是1：1，您也应始终拥有视图模型。我会关注实际原因而不是数据库层耦合。
域，实体框架，nhibernate或linq 2 sql模型作为您的视图类的问题是您无法很好地处理上下文验证。例如，给定用户类：
当一个人在您的网站上注册时，他们会看到一个用户界面，然后您：
当管理员编辑用户的名字后，他们会看到一个用户屏幕，然后：
现在通过FluentValidation，DataAnnotations属性或业务类上的自定义IsValid（）方法公开上下文验证，并仅验证名称和电子邮件更改。你不能。您需要将不同的上下文表示为不同的视图模型，因为这些模型的验证会根据屏幕表示而更改。
以前在MVC 1中，你可以通过简单的不发布你不想验证的字段来解决这个问题。在MVC 2中，这已经改变，现在模型的每个部分都得到验证，发布或不发布。
答案 3 :(得分：0)
在较大的项目中，我通常将数据对象中的业务对象拆分为一种风格。这是让程序和数据库都发生变化并且只影响控制（或VM）层的更简单的方法。