ASP.NET MVC: ¿Nesting ViewModels entre sí, antipattern o no?

Question

Tengo un proyecto en el que ViewModels está anidado el uno dentro del otro de manera que esencialmente son una replicación de la jerarquía de dominio de tipo cadena. Por ejemplo, si nuestro dominio tiene las siguientes relaciones:

Organización tiene 1 a muchos entornos

Medio Ambiente tiene 1 a muchas máquinas

entonces habrá un OrganizationViewModel que tiene uno a muchos EnvironmentViewModels en el mismo, y EnvironmentViewModel tendrá de uno a muchos MachineViewModels. Este estilo de jerarquía se reutiliza en toda la aplicación, con uno de los cinco modelos de vista de este tipo. (por ejemplo, EnvironmentViewModel se usa para varias páginas, MachineViewModel también para muchas de ellas, dependiendo del nivel de la jerarquía que se esté visualizando ... Lo simplifiqué para fines de discusión, pero la jerarquía es un poco más grande que las 3 anteriores)

Ahora, por mucho que me gustaría bajar desde arriba y condenar esta práctica, no he podido encontrar mucha información sobre esto. ¿Alguien puede indicarme más detalles sobre la práctica establecida? Anécdotas para compartir?

(Mi propio error es que estos ViewModels no deben anidarse entre sí de esta manera, y los ViewModels en realidad deberían corresponder a las Vistas, no a los objetos de dominio. Me parece bastante complicado con algunos problemas de mantenimiento. 'gustaría saber lo que otros piensan o han experimentado.)

I've attached this question for reference but it describes nesting a domain object within a viewmodel, not viewmodels within each other.

Answer 1

El modelo de vista debe ser lo más plana posible (aunque utilizan objetos inmutables anidados para agrupar lógicamente relacionados con múltiples propiedades están bien para poner en orden los propósitos).

No lo piense como "el modelo de vista debe corresponder a la vista", piénselo al revés: "la vista es una representación html de los datos del modelo de vista".

ViewModel es un término horrible porque no es una vista y no es un modelo, es una representación de un recurso.

Si hago:

`GET /User/1` 

espero volver algunos datos que representan usuario 1. Si eso es en formato HTML porque me enviaron

`Accept: text/html` 

entonces que así sea. Considera cómo se vería tu modelo de vista como XML o JSON.

tratar de evitar ViewModels anidación como usted es la creación de una cadena de dependencias, simplemente duplicar las propiedades, usted no está realmente viola SECO

Answer 2

Hemos seguido el artículo de Josh Smith Simplifying the WPF TreeView by Using the ViewModel Pattern en el pasado. Aunque es con WPF en lugar de MVC, creo que el concepto sigue siendo aplicable. Me pareció un mecanismo razonable para separar las preocupaciones de la pantalla en cada contexto y permitir una mayor flexibilidad con la reutilización.

HTH

Answer 3

diría modelos de vista anidados están bien. Sé que los modelos de vista son para una vista en particular, pero me parece un poco derrochador no hacer uso de mi ViewModel de direcciones anidando en varios otros modelos de vista. Ciertamente hace que actualizarlo sea mucho más fácil y le da una buena estructura.

Intento mantener la mía lo más plana posible, aunque normalmente un nivel de anidación satisface la mayoría de los escenarios que he encontrado.

pregunta relacionada Me respondió aquí: Two models in one view in ASP MVC 3

Answer 4

ViewModels deben estar asociados con los conceptos de interfaz de usuario, no necesariamente conceptos de dominio. Entonces, en su ejemplo, puedo imaginar una pantalla que muestra los detalles de la organización y una lista de Entornos; al hacer clic en un entorno, aparece una pantalla de detalles que muestra una lista de las máquinas; y hacer clic en uno de ellos lo lleva a la Vista de detalles de la máquina.

En ese ejemplo, hay 2 vistas diferentes de un entorno o máquina, la vista de resumen que ocupa una fila en el listado y la vista de detalles que ocupa la mayor parte de una pantalla, cada una debe tener su propio ViewModel. Probablemente crearía ViewModels para esto así:

OrganizationDetailsViewModel 
----List of EnvironmentSummaryViewModels 


EnvironmentDetailsViewModel 
----List of MachineSummaryViewModels 

MachineDetailsViewModel 

Dependiendo de cuán compleja es su interfaz de usuario, esta anidación puede ser más profunda. Imaginemos que tiene un pequeño indicador de estado gráfico para el entorno que mira el estado y se muestra en un determinado color. Podría crear un EnvironmentStatusViewModel separado que luego se anidaría dentro del EnvironmentSummaryViewModel y posiblemente también anidado dentro del EnvironmentDetailsViewModel.

Answer 5

Todavía quiero saber las ventajas ... y las desventajas. ¿Es más rápido o más simple de leer? Si usted tiene una vista que necesita representar toda la información, ¿no es más fácil obtener todo lo que desea mostrar en una sola base de datos obtener en lugar de múltiples conexiones parásitas?

En una vista, ¿no querría el usuario ver el "resumen de organización" que incluye todos los "Ambientes" y "Máquinas" asociados? Los recuentos de los elementos potencialmente anidados, si no otra cosa. (No el entorno y los detalles de la máquina: estos merecen diferentes vistas)

Parece haber una inclinación hacia la construcción de vistas para cumplir con una sola responsabilidad (Ver máquina (solo muestra información de la máquina) -> Ver detalles de la máquina (solo muestra Máquina Detalle)) Sería lo suficientemente simple para que esto ocurra, pero llega un momento en que las vistas no son ricas en características, ya que simplemente hay muy poca información.