¿Debo volver a usar la vista de modelos en diferentes vistas?

Question

Me di cuenta de que tengo vistas que necesitan la misma información que otras. Pero a veces se necesita 5 propiedades del modelo de vista y a veces sólo 2.

¿Usted cuota de vista de estos modelos sobre muchos puntos de vista o te crea un modelo separado vista para cada vista o tal vez hace que prefere un herencia o composición estrategia?

Para mí hay algunas desventajas para los modelos de vista intercambio:

1. Principio de la menor sorpresa: Es extraño para llenar sólo 2 propiedades de 5 de un modelo de vista y obtener excepción de referencia nula, porque usted don' Quiero consultar datos adicionales de la base de datos. Cuando el modelo de vista tiene 5 propiedades, espero que todas estén llenas. Las excepciones prueban la regla.
2. Separación de preocupaciones/Principio de responsabilidad única: el modelo de vista se amontona en sitios complejos, porque debe satisfacer las diferentes necesidades de cada vista. Si la lógica está involucrada, es cada vez más complejo.

¿Qué opinas? ¿Cómo manejas esas circunstancias?

Answer 1

En el proyecto en el que estoy trabajando, cada vista tiene su propio modelo de vista, sin embargo, también tenemos CollectionViewModels, que son compartidos/referenciados por varios modelos de vista.

Think: una lista de Proveedores, que debe mostrarse en múltiples pantallas en su aplicación, y está sujeta a una variedad de controles: un cuadro de lista, una vista de cuadrícula, lo que sea que necesite. Tener solo un ViewModel simplifica la actualización/actualización de la lista de Proveedores.

TLDR: Solo reutilizaría los modelos de vista, si todos los casos de uso utilizan ViewModel de la misma manera. Es decir. todos usan las mismas propiedades, etc.

Answer 2

Tendría un ViewModel independiente para cada vista. Las propiedades no utilizadas hacen que el código sea menos legible (¿Por qué está presente esa propiedad si no se está utilizando?). Si tiene la misma funcionalidad para un conjunto fijo de propiedades en varias vistas, podría ver el uso de una clase base que contenga esas propiedades.

Answer 3

Normalmente comparto ViewModels. Según tengo entendido, las ventajas de usar modelos de vista son (a) la seguridad, en el sentido de que las propiedades que deben ocultarse son y (b) la separación de las preocupaciones entre las capas de negocios y de presentación. (b) se realiza de la misma manera al compartir modelos de visualización.

En cuanto a (a), rara vez estoy en una situación en la que exponer una propiedad es un riesgo de seguridad en un lugar pero no en otro. Si una propiedad necesita estar oculta, probablemente deba estar oculta en todas partes. Por supuesto, YMMV, pero esto parece una pregunta bastante subjetiva.

Answer 4

Utilizo Entity Framework con Code First, por lo que las clases de mi dominio deben permanecer bastante rígidas, ya que se asignarán a una base de datos sql.

Algunas vistas usan solo una entidad directamente mapeada y eso es genial, así que uso la misma entidad de capa de dominio. Si esa entidad requiere más información (dos campos de contraseña, por ejemplo) usaré la composición. 'La composición debe favorecerse más que la herencia', por lo tanto, si puede usar la composición, usualmente, ya que solo se trata de propiedades adicionales, se puede usar la composición.

Si hay una pantalla que usa solo dos propiedades de esa entidad, o si deseo ocultar propiedades debido a problemas de seguridad, creo un nuevo modelo de vista y solo recupero los datos necesarios. Reutilizaré los modelos de vista, pero solo si se requieren las mismas propiedades en esa otra vista.

Answer 5

Las personas tienden a tener diferentes filosofías de ViewModels en función de su perspectiva de su uso. ViewModels es el pegamento entre una vista y un modelo y las personas generalmente basan su respuesta en cuál de los dos extremos les gusta mantener más rígido.

• Si te gustan los objetos de modelo/datos a ser más rígidos, entonces te tienden a atar el modelo de vista más cercano al modelo de datos/— es decir que tendrá un único modelo de vista que se utiliza en múltiples puntos de vista y deje que ViewModel determine qué propiedades recuperar según la forma en que desee manejar la carga de datos (y aplazar cosas como imágenes u otras propiedades de carga larga, etc.).
• Si desea que sus Vistas sean más rígidas, vinculará ViewModel a View —, es decir, tendrá un ViewModel separado para cada vista y permitirá que los objetos de modelo/datos manejen cosas como la sincronización mientras se mueve de la vista a ver.

Personalmente, prefiero el primero como mis datos tiende a ser más rígida porque es menos probable que cambie a los puntos de vista son (en mis proyectos — No creo que eso es una propiedad universal de datos y puntos de vista) Como las notificaciones de cambio son una característica natural de ViewModels, no tengo que hacer que mis objetos de modelo comuniquen cambios si un usuario tiene dos vistas que muestran los mismos datos/similares.

Answer 6

Definitivamente un ViewModel per View, imho.

A medida que su aplicación crece en complejidad, los modelos de vista compartidos tenderán a crecer, y no se siente bien pasar un objeto con 50 propiedades a una vista cuando todo lo que necesita es una propiedad.

Además, a veces es posible que desee agregar propiedades adicionales en su ViewModel que son absolutamente específicas para su vista y que no necesita en otras vistas. Supongamos que tiene una clase de CSS que depende de las propiedades de ViewModel. En lugar de escribir declaraciones if else en su Vista, crea una propiedad en el ViewModel que devuelve la clase css correcta en función de las reglas comerciales que tenga. De esta forma, haces que la Vista sea lo más pequeña posible y con un ViewModel dedicado no estás compartiendo un nombre de clase CSS con Vistas que realmente no se preocupan por él.

Answer 7

Compartía una máquina virtual entre vistas múltiples solo si todas las vistas usaban todas las variables de propiedades y métodos, de lo contrario utilizaría la herencia y el modelo de vista base abstracta y, si esto no resuelve. Hacer 1 a 1