porque - ¿Cómo se pueden usar los convertidores WPF en un patrón MVVM?

porque usar mvvm xamarin (5)

Añadiré mis 2 centavos a esta discusión.

Yo uso convertidores, donde tiene sentido.

Explicación: hay casos en los que necesita representar 1 valor en Modelo de más formas en la interfaz de usuario. Expongo este valor a través de 1 tipo. El otro tipo es manejado a través del convertidor. Si tuviera que exponer 1 valor a través de 2 propiedades en la máquina virtual, tendría que manejar manualmente las notificaciones de actualización.

Por ejemplo, tengo un modelo con 2 ints: DoneCount , DoneCount . Ahora quiero que estos dos valores se muestren en TextBlocks y, además, quiero mostrar el porcentaje realizado.

Resuelvo esto utilizando el convertidor múltiple DivisionConverter que toma 2 entradas previamente mencionadas.

Si tuviera un PercentDone especial en VM, necesitaría actualizar esta propiedad cada DoneCount se actualice DoneCount .

Digamos que tengo una vista que está vinculada a ViewModel A que tiene una colección observable de clientes .

Una ventaja de este patrón MVVM es que también puedo vincular la Vista a ViewModel B que la llena con datos diferentes.

Pero, ¿qué ocurre si en mi Convertidor de vista se muestran los Convertidores a mis clientes? Por ejemplo, tengo un "ContractToCustomerConverter" que acepta un Contrato y devuelve el Cliente apropiado para que se muestre.

El problema con esto es que el convertidor existe fuera del patrón MVVM y, por lo tanto, no sabe que mi ViewModel tiene otra fuente para los clientes.

¿Hay alguna forma para que la Vista pase el ViewModel al Convertidor para que participe en el desacoplamiento que proporciona el patrón MVVM?
¿Hay alguna manera de incluir el Convertidor en mi ViewModel para que el convertidor use las dependencias actuales que ViewModel tiene disponibles?
o los convertidores simplemente tienen un código subyacente glorificado y, por lo tanto, no se utilizan en el patrón MVVM, por lo tanto, si está utilizando MVVM, simplemente crea sus propios "convertidores" (métodos en su clase ViewModel) que devuelven elementos como objetos de imagen, objetos de visibilidad, objetos de flujo , etc. para ser usado en la vista, en lugar de usar convertidores?

(Me encontré con estas preguntas después de ver el uso de Convertidores en la aplicación de demostración WPF que viene con la descarga del kit de herramientas de plantillas MVVM , consulte la "Muestra de Messenger" después de desempaquetarla).

En esta conversación hay un comentario que está de acuerdo con la posición de Kent, de no usar convertidores, interesante:

Un ViewModel es básicamente un convertidor de valores en los esteroides. Toma datos "sin procesar" y los convierte en algo fácil de presentar, y viceversa. Si alguna vez se encuentra vinculando una propiedad de un elemento a una propiedad de ViewModel, y está usando un convertidor de valores, ¡deténgase! ¿Por qué no solo crea una propiedad en el ViewModel que expone los datos "formateados" y luego elimina el convertidor de valores por completo?

Y en esta conversación :

El único lugar donde puedo ver un uso para convertidores de valor en una arquitectura MVVM son los enlaces entre elementos. Si estoy vinculando la Visibilidad de un panel al IsChecked de un CheckBox, entonces tendré que usar el convertidor BooleanToVisibility.

Para aquellos que efectivamente dicen que no hay "convertidores no triviales" en la vista, ¿cómo maneja lo siguiente?

Digamos que tengo un modelo de sensores climáticos que representa series temporales de lecturas de varios instrumentos (barómetro, higrómetro, termómetro, etc.) en una ubicación determinada.

Digamos que mi View Model expone una colección observable de los sensores de mi modelo.

Tengo una vista que contiene un conjunto de datos de WPF Toolkit que se enlaza al modelo de vista con la propiedad ItemsSource establecida en una colección observable de sensores. ¿Cómo represento la vista de cada instrumento para un sensor dado? Al mostrar un pequeño gráfico (piense en la línea de sparkline Edward Tufte aquí) que se genera al convertir la serie de tiempo a una fuente de imagen usando un convertidor ( TimeSeriesToSparklineConverter )

Así es como pienso en MVVM: el modelo expone los datos a los modelos de vista. El modelo de vista expone el comportamiento, los datos del modelo y el estado a la vista. Las vistas hacen el trabajo de representar visualmente los datos del modelo y proporcionan una interfaz para comportamientos coherentes con el estado del modelo de vista.

Por lo tanto, no creo que las imágenes de chispas entren en el Modelo (el Modelo es datos, no una representación visual particular de él). Tampoco creo que las imágenes de línea de chispa se incluyan en el Modelo de vista (¿qué sucede si mi Vista quiere representar los datos de forma diferente, por ejemplo, como una fila de cuadrícula que muestra los valores mínimo, máximo, promedio, desviación estándar, etc. de la serie? Por lo tanto, me parece que la Vista debe manejar el trabajo de transformar los datos en la representación deseada.

Entonces, si quiero exponer los comportamientos, los datos del modelo y el estado dado para un determinado modelo de vista en una interfaz de línea de comandos en lugar de una GUI de WPF, no quiero que mi modelo ni mi modelo de vista contengan imágenes. ¿Esto esta mal? ¿Debemos tener un SensorCollectionGUIViewModel y un SensorCollectionCommandLineViewModel ? Eso me parece mal: pienso en el modelo de vista como una representación abstracta de la vista, no concreta y ligada a una tecnología particular como lo sugieren estos nombres.

Ahí es donde estoy en mi comprensión en constante evolución de MVVM. Entonces, para aquellos que dicen no usar convertidores, ¿qué están haciendo aquí?

Por lo general, no uso convertidores en MVVM, excepto para tareas de UI puras (como BooleanToVisibilityConverter, por ejemplo). En mi humilde opinión, deberías declarar una propiedad del Cliente del tipo CustomerViewModel en tu ContractViewModel, en lugar de usar un ContractToCustomerConverter

Los convertidores rara vez deben utilizarse con MVVM. De hecho, me esfuerzo por no usarlos en absoluto. La máquina virtual debe hacer todo lo que la vista necesita para hacer su trabajo. Si la vista necesita un Customer basado en un Contract , debe haber una propiedad del Customer en la VM que la lógica de la VM actualice cuando el Contract cambie.

Una ventaja de este patrón MVVM es que también puedo vincular la Vista a ViewModel B que la llena con datos diferentes.

Yo cuestiono esa afirmación. En mi experiencia, las vistas no se comparten entre diferentes tipos de VM, y tampoco es un objetivo de MVVM.