Estoy trabajando en una aplicación WPF y entiendo elpatrón de comando bastante bien, pero he encontrado que hay varias implementaciones diferentes del patrón de comando para MVVM. Hay una implementación de Josh Smith en su aplicación de ejemplo WPF, el DelegateCommand de prisma, y la CommandBindings implementación.
Mi pregunta es, ¿cuál es la mejor práctica generalmente aceptada para usar comandos con MVVM? Mi aplicación usa Prism tan DelegateCommand está disponible para nosotros.
Los desarrolladores de mi equipo están discutiendo sobre cuál es el mejor enfoque ". A algunos no les gustan los numerosos archivos .cs generados para cada comando, otros prefieren que todo se conecte a través de CommandBindings. Estoy perdido. ¿Alguien puede arrojar algo de luz?
Respuestas
2 para la respuesta № 1Dos puntos a considerar:
Los comandos proporcionados por diferentes MVVMlos marcos, como CommandSinkCommand o SimpleCommand (de Cinch), etc. funcionan como lo hacen los ICommands normales. En particular, el controlador CanExecute se evalúa cada vez que WPF cree que ha ocurrido algo que podría causar un cambio en la interfaz de usuario. También puedes forzar esto manualmente CommandManager.InvalidateRequerySuggested().
En contraste con eso, los DelegateCommands <> de Prism no llaman al controlador CanExecute a menos que usted llame manualmente RaiseCanExecuteChanged() en el comando. Si desea cambiar esto para que también se active cuando los comandos son requeridos normalmente, vea el código en http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338
EDITAR:
Segundo punto: Los comandos de los marcos MVVM generalmente aceptan un objeto como parámetro de comando. En contraste, los DelegateCommands <> de Prism están más tipificados (aunque, por supuesto, podría tener un DelegateCommands si lo desea).
3 para la respuesta № 2
Bueno, creo que no hay el solución.
Los CommandBindings no son fáciles de probar e introducen una dependencia a las clases de WPF en ViewModel, lo cual no es muy bueno. Así que no los usaría.
Tanto DelegateCommand como CommandSinkCommand (JoshLa solución de Smith) son buenas maneras, OMI. No son realmente diferentes y ninguna de ellas es superior a la otra. Sin embargo, noté que la versión de CommandSink no funciona siempre cuando el enrutamiento de comandos se vuelve más complejo (especialmente cuando se trata de DataTemplates).
Incluso puedes combinarlos: Use DelegateCommand y adicionalmente use la versión de JoshSmith, para que pueda combinar las ventajas de ambos. Lo único que necesitas son algunas clases de ayuda, no realmente difíciles de implementar.
Mucho más importante es la consistencia en su aplicación: si decidió lo que quiere usar, debe seguir de esta manera toda su aplicación.