¿Debería su ViewModel exponer elementos XAML como propiedades o no?

Question

En la pregunta de StackOverflow ¿Cómo se pueden usar los convertidores WPF en un patrón MVVM? he aprendido que los convertidores de valor no deben usarse en el patrón MVVM ya que la funcionalidad de un convertidor de valores debe ser manejada por ViewModel en sí .

Esto tiene sentido.

Pero recuerdo haber leído que no debería exponer elementos XAML a la Vista , sino exponer solo colecciones de datos que la Vista luego vincula y muestra usando DataTemplates.

Sin embargo, los convertidores parecen bastante potentes (p. ej., ya que se utilizan en Demostración de plantilla MVVM , vea & Quot; Muestra de Messenger & Quot; después de desempacarla) en que pueden convertir objetos en objetos , por ejemplo Objetos de mensaje a objetos de FlowDocument, u objetos de Cliente en objetos de Visibilidad, u objetos de Estado personalizados en Imágenes, etc.

Entonces, si un ViewModel va a asumir la funcionalidad de un Convertidor de Valor , tendrá que exponer elementos y propiedades XAML como StackPanel, Visibilidad, Color, FlowDocument, etc., ¿derecho?

¿Alguien ve alguna razón por la cual un ViewModel no debe exponer estos objetos XAML ricos como lo hacen los Convertidores de Valor?

Answer 1

Porque entonces eso limita el ViewModel para ser usado solo con una representación visual específica. Una vez que tiene el ViewModel que emite XAML, coloca el contenido del diseño en el dominio de un desarrollador. Esto significa que el diseñador que usa Expression Blend no puede editar los activos de diseño, y el flujo de trabajo del diseñador / desarrollador no funciona. Mantener el XAML en la página y usar convertidores de valor con plantillas de datos mantiene el diseño separado del código.

Cuando su ViewModel expone XAML específico, también limita que ViewModel se use solo en esa instancia específica y lo hace menos reutilizable.

Answer 2

No olvides que también puedes usar DataTemplates. Puedo ver algo de sentido en mantener ValueConverters fuera de MVVM, pero DataTemplates se trata de transformar objetos en GUI.

Su ViewModel puede exponer otros objetos (por ejemplo, ViewModels anidados) a la GUI, y la GUI puede usar <DataTemplate DataType="{x:Type SubViewModel}">... para asignar esos objetos a la GUI.

Answer 3

  

¿Alguien ve alguna razón por la cual un ViewModel no debe exponer estos objetos XAML ricos como lo hacen los Convertidores de Valor?

Absolutamente, porque socava todos los objetivos de MVVM:

1. Ya no puedes probar la unidad, al menos no fácilmente.
2. Ya no tiene separación entre lógica (ver modelo) y presentación (ver). Por lo tanto, los diseñadores y desarrolladores no pueden colaborar fácilmente.
3. El mantenimiento del código es más difícil porque ha mezclado las preocupaciones juntas.

Si vi un modelo de vista que devuelve una vista, ni siquiera lo clasificaría como MVVM.

Answer 4

Creo que una idea de mvvm / mvc / mvp, etc. es aislar el código GUI en un archivo / clase. Si hace esto, ¿puede cambiar a otra IU sin reescribir los otros objetos? Creo que si estás pasando objetos específicos de WPF, la respuesta es no. Es un juicio de valor que tendrá que tomar por sí mismo.

Answer 5

No existe una regla absoluta del 100% que funcione para este o muchos otros conceptos cuando los discute sin la perspectiva de por qué la mente de la comunidad ha cambiado como lo ha hecho en esta dirección. No existe una verdad o ciencia "asumida" en la "sabiduría convencional", independientemente de lo nueva o convincente que sea en ese momento.

En otras palabras, solo haz lo mejor con tu equipo como si fueras bueno, ya te están desanimando mucho más en las preocupaciones humanas que nada tan real como esto.