¿Por qué dos clases, modelo de vista 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 Crear controlador para crear usuarios, alguien podría alterar mi formulario y obtener POST un IsAdmin = verdadero valor de formulario, incluso si yo no expuse ese campo de texto en mi vista . Si utilizo el enlace de modelo, cuando haya confirmado mi modelo de dominio, esa persona ahora será un administrador. Así que la solución se convierte en una exposición de las propiedades que necesito en el modelo de vista y el uso de una herramienta como AutoMapper para asignar los valores de propiedad de mi objeto de modelo de vista de retorno a la de mi objeto de modelo de dominio. Pero leí que el atributo de vinculación en una clase se puede utilizar para indicar al Encuadernador de modelos qué propiedades debería y no debería unir. Entonces, ¿cuál es realmente la razón para hacer dos clases separadas (modelo de dominio y modelo de vista) que esenciales representan lo mismo y luego incurrir en gastos indirectos al mapearlos? ¿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 que he encontrado para una vista del modelo que está separado del modelo de dominio es la necesidad de implementar el patrón MVVM (basado en el patrón de PM de Martin Fowler) para la gestión UI complejas.

Answer 1

He descubierto que, aunque mi modelo de dominio me proporciona el 85% de 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 debería tener acceso a ciertas partes de la vista.

El concepto de diseño que intento seguir es tener la menor lógica en mi punto de vista posible. Esto significa que tengo campos en mi modelo de vista como "CanViewThisField" o "CanEditThisField". Cuando comencé con MVC, mi modelo de dominio era mi modelo de vista y siempre me encontraba con el escenario en el que necesitaba uno o dos campos más para que mi vista no fuera tan abarrotada. Desde entonces he pasado la ruta View Model/Model Builder y me ha funcionado maravillosamente. No peleo mi código por más tiempo, pero puedo mejorar mi modelo de vista según lo necesito sin afectar el modelo de dominio.

Answer 2

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

Answer 3

Otra buena razón para tener un ViewModel es buscar grandes conjuntos de datos. Podría pasar la vista una matriz de Persona (Person[]), pero los metadatos como el número de páginas, el número de la página actual y el tamaño de la página no pertenecerían a la clase Person.

Por lo tanto, un PersonListViewModel resolvería este problema.

Answer 4

Un ViewModel contiene solo aquellos miembros requeridos por la Vista. Por lo general, pueden considerarse como una simplificación o un "aplanamiento" del modelo de dominio subyacente.

pensar en ellos como esto:

• modelo de vista: este es el dato que es apropiado para hacer en este vista
• modelo de dominio: esta es toda la información de mi aplicación necesita acerca de esta entidad con el fin de realizar toda su funcionalidad

Por ejemplo, mi clase de orden tiene un miembro llamado Cliente que es una asociación composition, es decir, mi pedido tiene un cliente. Este objeto Cliente tiene miembros como Nombre, Apellido, etc. Pero, ¿cómo lo mostraría en una vista de "detalles" del pedido o una lista de Pedidos y los Clientes que los colocaron?

Bueno, usando un ViewModel puedo tener un OrderListItemViewModel que tiene un miembro CustomerName y puedo asignar la combinación de Firstname y Lastname del objeto Customer a esto. Esto se puede hacer de forma manual, o muy preferiblemente usando Automapper o similar.

Al usar este enfoque, puede tener varios modelos de vista de pedido que son específicos para diferentes vistas, p. Ej. la vista de lista de pedidos puede 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 superfluos que no se requieren del objeto de dominio subyacente en una vista, p. Si estoy viendo una lista de pedidos, ¿realmente quiero ver toda la información de contacto del cliente, los detalles de facturación, etc.? Supongo que eso depende del propósito de la lista, pero probablemente no.

Answer 5

Es necesario recordar que su domain model classes solamente se utilizan internally; es decir, nunca se envían al cliente . Para eso se usan los tipos de modelo de servicio (Ver tipos de modelo): representan los datos que irán y volverán entre el cliente y su servicio.