En Asp.net MVC, ¿es aconsejable que viewmodels se derive de modelos de dominio?

(Estoy usando ASP.Net MVC, pero esta parece ser una pregunta MVC más genérica)En Asp.net MVC, ¿es aconsejable que viewmodels se derive de modelos de dominio?

Supongamos que tiene un modelo de dominio que representa a una persona y tiene una vista para editar a una persona. El objeto de dominio Person incluye una propiedad de estado de residencia y en la vista desea un menú desplegable que enumere los estados.

¿Hay alguna razón para no crear un modelo de vista que se derive del modelo de dominio y que simplemente incluya propiedades para la pizca de interfaz de usuario que la vista requiere? Si es así, ¿por qué no querría hacer esto?

TIA

Fuente

2010-08-23 erg39

Me gustaría pensar que derivar un modelo de vista de un modelo de dominio introduciría acoplamiento que MVC se pretende evitar; sin embargo, dicho esto, haz lo que tenga más sentido para tu aplicación.

Prefiero tener modelos de vista separados porque al hacerlo me deja libre para cambiar drásticamente el modelo de dominio y obtener una mejor compatibilidad con tiempo de compilación para reasignar mi modelo de vista al nuevo modelo de dominio.

Fuente

2010-08-23 21:37:52 kbrimington

"el modelo de dominio introduciría el acoplamiento que MVC estaba destinado a evitar" Esta afirmación no es verdadera en absoluto. Implementaciones de Django/RoR en las que los modelos de vista son en realidad representaciones estrechamente acopladas del esquema de la base de datos. MVC no hace una opinión sobre cuál debería ser su modelo, solo que no es parte de su V y C. – jfar

De Wikipedia: Muchas aplicaciones usan un mecanismo de almacenamiento persistente como una base de datos para almacenar datos. MVC no menciona específicamente la capa de acceso a datos porque se entiende que está debajo o encapsulada por el modelo. Los modelos no son objetos de acceso a datos; Sin embargo, en aplicaciones muy simples que tienen poca lógica de dominio, no hay una distinción real que hacer. Active Record es un patrón de diseño aceptado que combina la lógica de dominio y el código de acceso a datos, un modelo que sabe cómo persistir. – jfar

@jfar: Su punto está bien; sin embargo, muchos de los ejemplos de MVC usan Linq-to-SQL o Linq-to-Entities o DataSets * como * el modelo de dominio. Todos estos modelos tienen al menos algún acoplamiento al mecanismo de almacenamiento persistente, y se usan como modelos (con frecuencia suficiente) en la práctica. – kbrimington

No, realmente no desea hacer esto.

Una gran parte de la razón para usar ViewModels es porque las entidades de tu dominio tienden a ser grandes, puntiagudas, complejas y vinculadas a mecanismos de persistencia. Todo lo cual lleva a que tengan comportamientos extraños, interesantes o destructivos cuando se encuentran con cosas como DefaultModelBinder.

Al utilizar clases de ViewModel mucho más simples, puede evitar la mayor parte de estos problemas a la vez que desacopla aún más la capa de la interfaz de usuario de su modelo de dominio.

Ahora, lo que debe hacer es proporcionar medios sencillos para generar un modelo de vista desde una entidad de dominio o actualizar una entidad de dominio desde un modelo de vista.

Fuente

2010-08-23 21:38:07

+1 para el comentario sobre la tendencia de las entidades de dominio a vincularse a los mecanismos de persistencia. Encuentro que con POCOs para un modelo de vista es menos probable que encuentre un comportamiento de serialización extraño. – kbrimington

Podría ampliar el comentario "lo que debe hacer es proporcionar medios fáciles de generar un modelo de vista desde una entidad de dominio o actualizar una entidad de dominio desde un modelo de vista". ¿Te refieres genéricamente? Escribir un montón de código de actualización de entidad por modelo es algo que me gustaría evitar a menos que sea necesario. – erg39

Puede hacer varias cosas para facilitar el trabajo, como AutoMapper, pero dependiendo de qué tan lejos estén sus entidades y sus modelos de vista, podría tener algún código de manual para mantener. –

Esta no es una práctica recomendada y como usted está pidiendo no debería hacerlo. La respuesta breve es crear un modelo de vista único para cada vista que va a renderizar. Mantenga una vista de 1-1 para ver la relación del modelo y mientras codifica verá por qué.

La respuesta larga se puede encontrar aquí amoung otros lugares http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

Gracias,

Fuente

2010-08-23 21:38:28 Firegarden

Entiendo el uso de viewmodels, pero incluso el enlace que cita concluye "Si puede vincular directamente al modelo de dominio en casos simples, esa es la solución más simple y fácil". Escenarios como el citado en la publicación original es apenas más de lo que figura en el modelo de dominio (aunque no estoy argumentando que podría no derrumbarse si crece en complejidad). Entiendo que muchos (¿la mayoría?) Se sienten derivando un modelo de vista del modelo de dominio CRUD no es ideal. Simplemente no entiendo, si usar el dominio es lo más simple y fácil, por qué este es el caso. Gracias. – erg39

-1

no estoy de acuerdo con la mayoría de los consejos aquí.

Creo que su modelo de dominio debe estar limpio y un modelo de vista hace lo que tiene que hacer. Si su vista necesita una persona y el tiempo en Londres no veo el problema de hacer esto:

ExampleViewModel : Person { 
Public DateTime LondonTime { get; set;} 
}

AnotherViewModel 
{ 
Public Person SomeGuy { get; set;} 
Public List<Kitty> Cats{ get; set;} 
}

Si su vista necesita una persona y una lista de los gatitos

Esto mantiene su dominio limpio; el horario de Londres no está relacionado con una persona, sin embargo, desde su punto de vista, aún necesita obtener los datos. Este es el punto total de un modelo de vista imho.

Fuente

2010-08-24 07:10:59 aaron

El primer ejemplo debería favorecer la composición sobre la herencia – mathieu

En Asp.net MVC, ¿es aconsejable que viewmodels se derive de modelos de dominio?

Respuesta

Cuestiones relacionadas