WPF ICommand vs RoutedCommand

icommand c#

Question

Vamos a tener un botón de propiedad de Command vinculado a un comando personalizado.

¿Cuándo debo implementar ICommand y cuándo derivar de RoutedCommand ? Veo que RoutedCommand implementa ICommand .

¿En qué caso podría necesitar multiplicar un ICommand ? ¿Qué pasa con el modelo MVVM? ¿Cuál se adapta mejor para este propósito?

Answer 1

Como ha notado, la clase RoutedCommand es una implementación de la interfaz ICommand , su principal distinción si su función es similar a la de un RoutedEvent :

Los métodos Execute y CanExecute en RoutedCommand no contienen la lógica de la aplicación para el comando como es el caso con un ICommand típico, sino que estos métodos generan eventos que atraviesan el árbol de elementos en busca de un objeto con un CommandBinding. Los controladores de eventos adjuntos al CommandBinding contienen la lógica de comando.

El método Execute genera los eventos PreviewExecuted y Executed. El método CanExecute genera los eventos PreviewCanExecute y CanExecute.

En el caso de que no desee el comportamiento de RoutedCommand , verá su propia implementación de ICommand . En cuanto al patrón MVVM, no puedo decir que una solución, parece que cada uno tiene su propia metodología. Sin embargo, aquí hay algunos enfoques para este problema que he encontrado:

• Usando RoutedCommands con un ViewModel en WPF
• Lógica de comando de retransmisión
• Comando simple (casi idéntico al comando de transmisión, pero vale la pena leerlo)

Answer 2

Lo único que agregaría a la respuesta de Rich McGuire es que RoutedCommands (y su descendiente más predominante, RoutedUICommand tienen que estar conectados con los controladores de eventos para que funcionen correctamente.

La mayoría de las implementaciones de MVVM que he encontrado intentan aprovechar el enlace contra ViewModel y, por lo tanto, ViewModel (y no la vista) posee la lógica CanExecute / Execute.

En contraste, los controladores de eventos mueven esa carga a la Vista. El manejo se puede propagar a ViewModel, pero esto significa un grado ligeramente mayor de acoplamiento entre ViewModel y View (casting + método de llamada, etc.).