ASP.NET MVC: using EF entities as viewmodels? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice?

Is is OK to use EF entities c开发者_C百科lasses as view models in ASP.NET MVC?

What if viewmodel is 90% the same of EF entity class?

Let's say I have a Survey class in Entity Framework model. It 90% matches data required for view to edit it. The only difference from what view model should have - is one or several properties to be used in it (that are required to populate Survey object because EF class cannot be directly mapped onto how it's properties are represented (sub-checkboxes, radio groups, etc.))

Do you pass them using ViewData[]? Or create a copy of Survey class (SurveyViewModel) with new additional properties (it should be able to copy data from Survey and back to it)?

Edit: I'm also trying to avoid using Survey as SurveyViewModel property. It will look strange when some Survey properties are updated using UpdateModel or with default binder, while others (that cannot be directly mapped to entity) - using SurveViewModel custom properties in controller.

---

I like using Jimmy Bogard's approach of always having a 1:1 relationship between a view and a view model. In other words, I would not use my domain models (in this case your EF entities) as view models. If you feel like you are doing a lot of work mapping between the two, you could use something like AutoMapper to do the work for you.

---

Some people don't like passing these model classes all the way through to the view, especially as they are classes that are tied to the particular ORM you're currently using. This does mean that you're tightly binding your data framework to your view types.

However, I have done this in several simple MVC apps, using the EF entity type as the Model for some strongly-typed views - it works fine and is very simple. Sometimes simple wins, otherwise you may find yourself putting a lot of effort and code into copying values between near-identical Model types in an app where realistically you'll never move away from EF.

---

You should always have view models even if they are 1:1. There are practical reasons rather than database layer coupling which I'll focus on.

The problem with domain, entity framework, nhibernate or linq 2 sql models as your view classes is you cannot handle contextual validation well. For example given a user class:

When a person signs up on your site they get a User screen, you then:

1. Validate Name
2. Validate Email
3. Validate Password Exists

When an admin edits a user's name they get a User screen, you then:

1. Validate Name
2. Validate Email

Now expose contextual validation via FluentValidation, DataAnnotations Attributes, or even custom IsValid() methods on business classes and validate just Name and Email changes. You can't. You need to represent different contexts as different view models because validation on those models changes depending on the screen representation.

Previously in MVC 1 you could get around this by simple not posting fields you didn't want validated. In MVC 2 this has changed and now every part of a model gets validated, posted or not.

---

Robert Harvey pointed out another good point. How does your user Entity Framework display a screen and validate double password matching?

---

On bigger projects, I usually split up business objects from data objects as a matter of style. It's a much easier way to let the program and database both change and only affect the control (or VM) layer.