WPF MVVM Uso de comandos frente a controladores de eventos

Question

Me gusta el patrón MVVM, una vez que empiezas a usarlo, te vuelves adicto a él.

Sé que en el mundo perfecto su código de vista detrás está casi vacío (quizás algún código en el constructor) y cada aspecto de la vista está siendo manipulado desde ViewModel.

Pero hay ocasiones en las que la creación de nuevos campos, propiedades y comandos en ViewModel crea más código que implementando lo mismo en el controlador de eventos.

Al momento en que se adhieren a siguiente regla:

Si el código de controlador de eventos manipula porción muy pequeña de su vista (por ejemplo, botón de controlador de eventos click aumenta la fuente de cierta TextBlock que está situado en el mismo punto de vista), entonces está bien implementar lógica dentro de los controladores de eventos. Pero si View necesita manipular la lógica empresarial o acceder a los recursos que están fuera de la vista, entonces asigno estas responsabilidades a ViewModel.

¿Qué opinas sobre mi enfoque?

¿Qué intenta evitar al usar controladores de eventos y ViewModel?

¿Qué mejores prácticas puede recomendar al usar el patrón MVVM?

Answer 1

Diría que su regla de oro no está nada mal.

En mi opinión, la preocupación principal es "¿es el código específico de la vista, o se trata de la lógica comercial?".

Está bien tener código en la vista, si ese código está estrictamente aquí para modificar la vista y no para llevar a cabo ningún tipo de lógica comercial. Su ejemplo de cambiar el tamaño de una fuente es un excelente ejemplo de código que está perfectamente bien en una vista (y aumentaría el ruido en un ViewModel, por lo que es más difícil de entender y mantener). En esencia, ya haces algo de eso si usas activadores, por lo que no es tan extraño.

Sin embargo, tenga en cuenta que si usa pruebas unitarias, será muy difícil probar ese bit de view-logic. Si lo necesita probado, será mejor que lo ponga en el modelo de vista.

Answer 2

creo que puedo añadir algo al comentario anterior, así,

En lugar de utilizar controladores de eventos, desde muy modesta experiencia, Comandos me da mucha más flexibilidad en el sentido de que proporciona un mecanismo independiente para responder a eventos/acciones de diferentes controles con la capacidad de verificar el estado del comando mismo.