primera - ¿Por qué los eventos y comandos en MVVM no son compatibles con WPF/Visual Studio?
xaml (5)
Al crear una aplicación WPF con el patrón MVVM, parece que tengo que reunir las herramientas necesarias para comenzar incluso el manejo de eventos más rudimentario, por ejemplo
Ahora estoy buscando una manera de manejar el evento ItemSelected en un ComboBox y obtengo sugerencias de trucos y soluciones para hacer esto (usar un disparador XAML o tener otros elementos vinculados al elemento seleccionado, etc.). Ok, puedo ir por este camino, pero parece estar reinventando la rueda. Sería bueno tener un comando ItemSelected que puedo manejar en mi ViewModel .
¿Me estoy perdiendo algún conjunto de herramientas estándar o todos están haciendo MVVM con WPF, básicamente construyendo y armando su propia colección de herramientas solo para que puedan hacer las tareas de plomería más simples con eventos y comandos, cosas que toman solo un par de líneas en el código subyacente? con un clic = "eventHandler"?
Becuase MVVM se "inventó" mucho después de WPF ... de ahí que las grandes piezas del rompecabezas de MVVM no formen parte del marco WPF.
No solo eso, sino que MVVM fue declarado un "patrón" antes de que fuera probado o practicado en el mundo real. Lo que es todo lo contrario de lo que son los patrones: generalmente son detectados y documentados después de muchos años de uso exitoso por muchas personas diferentes.
Un chico que viene con un patrón no hace un patrón.
Eche un vistazo a esta plantilla de proyecto MVVM para VisualStudio.
http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx
Con esta plantilla, obtiene varias clases de DelegateCommand que cubren diferentes necesidades de ICommands, y una clase CommandReference que ayuda con los enlaces de teclas.
Es un buen comienzo...
Me alegra saber que no soy el único que piensa que las implementaciones de mando por ahí son excesivas . El enlace de datos parece, naturalmente, bien soportado, pero me he estado golpeando la cabeza durante semanas tratando de comprender los enlaces de comandos para cosas que no sean botones y elementos que heredan de él.
Gracias por publicar esta pregunta. Creo que de ahora en adelante voy a manejar todos los eventos en la capa de vista con una redirección a las funciones del modelo de vista. Creo que así es como enseñaron MVVM básico en uno de los cursos de 2 días del XAMLFest de Microsoft. ¡Suficientemente bueno para mi!
Según el article Josh Smith sobre MVVM, fue presentado al mundo en octubre de 2005 en el blog de John Gossman .
A partir de ese momento, diría que WPF / MVVM tardó otros 2 o 3 años en despegar y ser aceptado por la comunidad, para ese entonces ya era demasiado tarde para adaptar WPF para soportar los problemas con MVVM. También diría que WPF creó MVVM, por lo que parece tener cambios en WPF para admitir MVVM.
Finalmente, no todos los usuarios de WPF utilizan MVVM, por lo que la API debe admitir el uso estándar de eventos, etc.
Entonces, para responder a su pregunta, sí, todos están actualmente reuniendo su propio conjunto de herramientas, ya que el soporte "oficial" solo proporciona el marco de DelegateCommands en este momento.
Tienes razón sobre la complejidad de los comandos. Intento seguir el patrón MV-VM lo más cerca posible, pero no puedo justificar soluciones sofisticadas solo para manejar un evento de usuario simple.
En mi opinión, está bien manejar un evento de usuario en la Vista si eso simplifica enormemente su código. Si maneja un evento de usuario en la Vista, el código subyacente de su Vista debe llamar inmediatamente a un método en el Modelo de Vista. De esta manera, aún mantendrá su lógica en ViewModel ... solo tendrá un pequeño código de plomería (controlador de eventos) en la Vista. Sé que los puristas de MV-VM piensan que no debería haber ningún código en el código subyacente de la Vista, pero a veces tiene más sentido permitir algún código simple como un controlador de eventos. Recuerde, otros pueden tener que leer / modificar su código en el futuro y es mucho más fácil entender un controlador de eventos que un DelegateCommand.