Pros y contras de tener unas características específicas de WPF en el modelo de vista

Question

estoy teniendo problemas para decidir qué pensar sobre este pedazo de código:

public SolidColorBrush Brush 
{ 
    get { return IsValid ? _validItemBrush : _invalidItemBrush; } 
} 

Es parte de un modelo de vista en mi proyecto actual y con las se puede imaginar, el Brush se vinculará a algunos elementos de texto en la interfaz de usuario, para indicar (in) la validez de otras piezas de datos, en un diálogo bastante simple y sencillo.

Los defensores de este fragmento de código dicen que, dado que estamos utilizando WPF, también podríamos permitir algunas construcciones simples de WPF en el modelo de vista.

Los opositores dicen que esto viola Separation of Concerns, ya que indica claramente el estilo que debe tenerse en cuenta únicamente por la vista.

Comparta sus argumentos, y si no está satisfecho con el código anterior, comparta sus ideas con soluciones alternativas. (Estoy particularmente interesado en lo que tiene que decir sobre el uso de DataTemplate s).

¿Es posible que haya una solución que se podría considerar mejor práctica?

Answer 1

Personalmente, quisiera hacer que los dos pinceles se definan en XAML, y tener los controles que los utilizan cambian los pinceles (en xaml) según la propiedad IsValid. Esto podría hacerse fácilmente con DataTriggers, o incluso con un solo IValueConverter: el convertidor podría tomar 2 pinceles y un booleano e intercambiarlos con bastante facilidad.

Esto mantiene la neutralidad de la presentación de la lógica de negocios: un "Pincel" es muy específico para una forma específica de presentación, y una opción de Vista pura. Codificar esto en el modelo de vista viola el principio de responsabilidad única y no es una separación clara de las preocupaciones.

Me gustaría mantener esto en la Vista, y cambiar basado en la propiedad IsValid (vinculada) que es específica de ViewModel.

Answer 2

Si bien hay circunstancias en las que podría utilizar construcciones WPF en el modelo de vista, este no es uno de ellos. He aquí por qué:

• Es más difícil de cambiar. Si define pinceles como recursos y los utiliza en estilos, cambiar el esquema de colores de la aplicación puede ser simplemente una cuestión de cargar un diccionario de recursos diferente. Si codifica valores de color en sus modelos de vista, tendrá que cambiar muchas cosas si resulta que los usuarios finales necesitan colores diferentes.

• Es más difícil de probar. Si desea escribir una prueba unitaria que compruebe si una propiedad devuelve el pincel correcto, debe crear un pincel en su prueba unitaria y comparar los valores de los dos, ya que es un tipo de referencia.

• En muchos casos, tal vez en la mayoría de los casos, no hace que el código sea más simple o más fácil de mantener. Es muy probable que ya esté usando un estilo (suponiendo que esté familiarizado con los estilos), ya que hacen que todo en WPF sea más fácil. Encuadernar IsValid para pintar colores es solo una cuestión de agregar un DataTrigger a un estilo. Que es donde cualquier persona que mantenga este código esperaría encontrarlo.

Es cierto que hay momentos en los que hago uso de WPF construye en el modelo de vista - por ejemplo, hace mucho tiempo dejó de preguntarse si era un problema si un modelo de vista expone una propiedad de tipo Visibility. Tenga en cuenta que ninguna de las preocupaciones anteriores se aplica a ese caso.

Answer 3

En casos como el suyo donde es puramente estético, uso Triggers o Visual State Manager para cambiar los colores.

A veces uso colores en mis modelos de vista, pero solo si forma parte de las especificaciones de mi software (por ejemplo, el color del gráfico que muestra el CO2 de un paciente depende de la localización). En ese caso, uso una propiedad de límite de Estructura de color, que permite a la Vista usar el Color para un SolidColorBrush, un GradientStop o lo que quiera. Inicialmente usé una cadena en formato #AARRGGBB para eliminar por completo la dependencia de WPF, pero a mis colegas más experimentados no les gustó.