.net - data - WPF MVVM que usa comandos frente a controladores de eventos
wpf combobox binding (2)
Yo diría que su regla de oro no es mala.
En mi opinión, la preocupación central es "¿es el código específico de la vista, o aborda 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 disparadores, por lo que no es tan extraño.
Sin embargo, tenga en cuenta que si usa pruebas unitarias, será muy difícil probar ese poco de lógica de visualización. Si lo necesita probado, será mejor que lo ponga en el modelo de vista.
Me gusta el patrón MVVM, una vez que empiezas a usarlo, te vuelves adicto a él.
Sé que en el mundo perfecto tu 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 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.
En este momento me atengo a la siguiente regla:
Si el código del controlador de eventos manipula una porción muy pequeña de su vista (por ejemplo, el controlador de eventos click click aumenta la fuente de cierto TextBlock que está ubicado en la misma vista), entonces está bien implementar la lógica dentro de los manejadores 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é piensas de mi enfoque?
¿Qué intenta evitar al usar controladores de eventos y ViewModel?
¿Qué mejores prácticas puede recomendar al usar el patrón MVVM?
Creo que puedo agregar algo al comentario anterior también,
En lugar de utilizar controladores de eventos, desde una experiencia muy modesta, los comandos me dan mucha más flexibilidad en el sentido de que proporcionan un mecanismo independiente para responder a eventos / acciones de diferentes controles con la capacidad de verificar el estado del comando en sí.