¿Por qué dos clases, ver modelo y modelo de dominio?

Question

Sé que podría ser malo usar modelos de dominio como modelos de vista. Si mi modelo de dominio tiene una propiedad llamada IsAdmin y tengo una acción de controlador Crear para crear usuarios, alguien podría alterar mi forma y hacer que publique un valor de formulario ISADmin = verdadero, incluso si no expongo dicho campo de texto en mi opinión . Si estoy usando la vinculación del modelo, cuando cometí mi modelo de dominio, esa persona ahora sería un administrador. Por lo tanto, la solución se vuelve exponiendo solo las propiedades que necesito en el modelo View y utilizando una herramienta como Automapper para asignar los valores de propiedad de mi objeto Modelo de vista de retorno a la de mi objeto Modelo de dominio. Pero leí que el atributo de enlace en una clase se puede usar para instruir al aglutinante modelo qué propiedades debe y no debe unirse. Entonces, ¿cuál es realmente la razón para hacer dos clases separadas (modelo de dominio y modelo de vista) que esencial representa lo mismo y luego incurre en la sobrecarga en el mapeo? ¿Es más un problema de organización del código y, de ser así, cómo me estoy beneficiando?

EDITAR

Una de las razones más importantes por las que he encontrado para un modelo de vista que está separado del modelo de dominio es la necesidad de implementar el patrón MVVM (basado en el patrón PM de Martin Fowler) para administrar UI complejas.

Answer 1

He descubierto que si bien mi modelo de dominio me consigue el 85% de la forma de tener los campos que quiero, nunca ha cubierto el 100% de los valores que quiero en mi opinión. Especialmente cuando se trata de permisos y si un usuario debe tener acceso a ciertas partes de la vista.

El concepto de diseño que intento seguir es tener la menor lógica posible en mis puntos de vista. Esto significa que tengo campos en mi modelo de vista como "CanviewThisField" o "Caneditthisfield". Cuando comencé con MVC, tendría que mi modelo de dominio sería mi modelo de vista y siempre me encontraba con el escenario en el que necesitaba solo uno o dos campos más para que mi vista fuera menos desordenada. Desde entonces he ido el Ver modelo/generador de modelos ruta y ha funcionado maravillosamente para mí. Ya no lucho por mi código, pero puedo mejorar mi modelo de visión como lo necesito sin afectar el modelo de dominio.

Answer 2

Otra buena razón para tener un Modelo ViewS es la paginación de grandes conjuntos de datos. Podrías pasar la vista una variedad de persona ( Person[] ) Pero metadatos como el número de páginas, el número de la página actual, el tamaño de la página no pertenecería a la Person clase.

Por lo tanto, una LISTVIEWMODEL de PersonListview resolvería este problema.

Answer 3

Un ViewModel contiene solo a los miembros que requieren la vista. Por lo general, pueden considerarse una simplificación o un "aplanamiento" del modelo de dominio subyacente.

Piense en ellos así:

• Viewmodel: Estos son los datos que son apropiados para renderizar en este punto de vista.
• Modelo de dominio: Esta es toda la información que mi aplicación necesita sobre esta entidad para realizar toda su funcionalidad

Por ejemplo, mi clase de pedido tiene un miembro llamado Cliente que es un composición asociación, es decir, mi pedido tiene un Cliente. Este objeto del cliente tiene miembros como FirstName, LastName, etc ... pero ¿cómo mostraría esto en una vista de "detalles" del pedido o una lista de pedidos y los clientes que los colocaron?

Bueno, usando un Modelo ViewModel, puedo tener una LISTITIMVIELMODELMODEL de OrderSistitemView que tenga un miembro de nombre de personal y puedo mapear la combinación de FirstName y LastName del objeto del cliente a esto. Esto se puede hacer manualmente, o muy preferiblemente usando Autófano o similar.

Usando este enfoque, puede tener modelos de visualización de pedidos múltiples que sean específicos para diferentes vistas, por ejemplo, la vista de la lista de pedidos podría representar el nombre del cliente de una manera diferente a la vista de detalles del pedido.

Otra ventaja de ViewModels es que puede reducir los datos extraños que no se requieren del objeto de dominio subyacente en una vista, por ejemplo, si estoy viendo una lista de pedidos, ¿realmente quiero ver toda la información de contacto del cliente, detalles de facturación,? etc...? Supongo que eso depende del propósito de la lista pero, probablemente no.

Answer 4

A veces debe mostrar los datos de manera específica (es decir, mostrar una fecha en el formato mm/dd/yyyy vs. yyyy/mm/dd) y, a menudo, es más fácil hacer esta propiedad en la vista y no en el dominio Modelo, donde (o debería) tener una asignación a una columna en su DB.

Answer 5

necesitas recordar que tu domain model classes solo se usan internally; es decir, nunca se envían al cliente. Para eso se utilizan los tipos de modelos de servicio (Ver tipos de modelos): representan los datos que irán y vendrán entre el cliente y su servicio.