ASP.NET MVC: ¿usar entidades EF como viewmodels?

Question

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

¿Es está bien usar las clases de EF entidades como modelos de vista en ASP.NET MVC?

¿Qué pasa si viewmodel es 90% el mismo de EF entity class?

Digamos que tengo una clase de encuesta en el modelo de Entity Framework. El 90% coincide con los datos requeridos para verlos para editarlos. La única diferencia de lo que debería tener el modelo de vista es una o varias propiedades para usar (que son necesarias para rellenar el objeto Survey porque la clase EF no se puede asignar directamente a cómo se representan sus propiedades (sub-checkboxes, grupos de radio, etc.))

¿Los pasa usando ViewData []? O cree una copia de la clase Survey (SurveyViewModel) con nuevas propiedades adicionales (¿debería poder copiar los datos de Survey y volver a ellos)?

Edit: También estoy tratando de evitar el uso de la propiedad Survey como SurveyViewModel. Se verá extraño cuando algunas propiedades de Encuesta se actualicen usando UpdateModel o con el enlace predeterminado, mientras que otras (que no se pueden asignar directamente a la entidad) - usando propiedades personalizadas de SurveViewModel en el controlador.

Answer 1

Me gusta usar Jimmy Bogard's approach de tener siempre una relación 1: 1 entre una vista y un modelo de vista. En otras palabras, no usaría mis modelos de dominio (en este caso, sus entidades EF) como modelos de vista. Si sientes que estás haciendo un gran trabajo de mapeo entre los dos, podrías usar algo como AutoMapper para hacer el trabajo por ti.

Answer 2

En proyectos más grandes, por lo general se dividen objetos de negocios a partir de objetos de datos como una cuestión de estilo. Es una forma mucho más fácil de dejar que el programa y la base de datos cambien y solo afecten la capa de control (o VM).

Answer 3

A algunas personas no les gusta pasar estas clases de modelo a la vista, especialmente porque son clases que están vinculadas al ORM particular que está utilizando actualmente. Esto significa que está uniendo estrechamente su marco de datos a sus tipos de vista.

Sin embargo, he hecho esto en varias aplicaciones MVC simples, usando el tipo de entidad EF como el Modelo para algunas vistas fuertemente tipadas, funciona bien y es muy simple. A veces, gana simple, de lo contrario, puede que te encuentres esforzándote mucho y codificando para copiar valores entre tipos de modelos casi idénticos en una aplicación donde de forma realista nunca te alejarás de EF.

Answer 4

Siempre debe tener modelos de vista, incluso si son 1: 1. Hay razones prácticas en lugar de un acoplamiento de capa de base de datos en el que me centraré.

El problema con los modelos de dominio, entidad marco, nhibernate o linq 2 sql como clases de vista es que no puede manejar bien la validación contextual.Por ejemplo dado una clase de usuario:

Cuando una persona se registra en su sitio consiguen una pantalla de usuario, entonces:

1. Validar
2. Validar correo electrónico
3. Validar Contraseña existe

Cuando un administrador edita el nombre de un usuario, obtiene una pantalla de Usuario, entonces usted:

1. Validar
2. Validar correo electrónico

Ahora exponga la validación contextual a través de FluentValidation, DataAnnotations Atributos, o incluso isValid personalizado() métodos en clases de negocios y validar sólo nombre y correo electrónico cambios. No puedes. Debe representar diferentes contextos como diferentes modelos de vista porque la validación en esos modelos cambia dependiendo de la representación de la pantalla.

Anteriormente en MVC 1 se podía evitar esto simplemente no publicando campos que no quería validados. En MVC 2 esto ha cambiado y ahora cada parte de un modelo se valida, publica o no.

---

Robert Harvey señaló otro buen punto. ¿Cómo muestra su Entity Framework de usuario una pantalla y valida la coincidencia de doble contraseña?