¿Por qué ICommand es mejor que el código detrás de llamar a la máquina virtual?

Question

Tengo un compañero de trabajo que me preguntó por qué tiene que usar el patrón ICommand.

Quiere agregar un botón y luego hacer un evento para él en el código detrás. Luego, desde el evento, quiere llamar a un método en ViewModel.

Le di la respuesta obvia: Esto agrega acoplamiento entre la Vista y el Modelo de Vista. Pero argumentó que View y ViewModel ya están acoplados. (Hemos creado DataContext de nuestra visión para el modelo de vista en el código de la vista atrás: DataContext = new MyViewModel();

Sí, le dije que su forma se suma "más de acoplamiento", pero sonaba un poco escaso incluso para mí

Así,. Sé que ICommand es la manera más limpia, y lo hago de esa manera. ¿Pero qué más le compra ICommand además de no utilizar un acoplamiento ya existente?

Answer 1

• No se trata de desacoplamiento, pero la profundidad que puede penetrar en el interior de su jerarquía modelview: No caso bombeo, pero el evento de enrutamiento , incorporada en el marco.

• Se trata de la interfaz de usuario: comando tiene estado (CanExecute), si asigna el comando al control, si el estado del comando se convierte en false, el control se desactiva. Le ofrece una forma de administración de estado de IU poderosa, evitando una gran cantidad de codificación de espagueti, especialmente para una IU complicada.

Answer 2

ICommand también le puede dar un lugar para manejar o no un botón específico se puede usar en ese momento. Esto se manejará a través del método canexecute.

Answer 3

Puede enlazar el CanExecute método del comando a las propiedades de un control, también un Command encapsula una acción de una manera agradable. En mi opinión/experiencia, este enfoque tiene mucho sentido porque tienes tanto la condición como la acción de ejecución en una sola abstracción, lo que hace que sea más fácil de entender y probar.

Si en el futuro encuentra que esta acción se repite, puede abstraerla fácilmente en su propio ICommand personalizado y utilizarla en varios lugares.

Answer 4

Tengo un compañero de trabajo que me preguntó por qué tiene que utilizar el patrón ICommand .

Parece implicaba esta es una norma en su empresa (ya sea explícitamente o tácito). Eso debería ser respuesta suficiente a su pregunta.

Si se supone que todo el código de la compañía usa ese patrón, puede causar confusión y frustración entre los desarrolladores cuando alguien más tiene que depurar su código.

Además, en mi opinión, el uso de ICommand es más rápido de desarrollar/simular porque no NECESITA tener la propiedad ICommand en el contexto para ejecutar su programa. Le permite a los diseñadores de su interfaz de usuario (si tiene la suerte de tenerlos) completar por completo sus tareas, incluso si está retrasada en la codificación.

Answer 5

Una cosa que no veo en las respuestas anteriores es que el uso de ICommand promueve la reutilización del código al permitir que la misma acción sea utilizada por diferentes componentes de la GUI.Por ejemplo, si tuviera un comando que debería dar como resultado la apertura de una ventana y ese comando podría invocarse en tres o para pantallas diferentes en la aplicación, una implementación de ICommand me permite definir esa lógica en un solo lugar. Con los manejadores de eventos de código subyacente, tengo que copiar y pegar código redundante, en violación de DRY (o de lo contrario, tendría que implementar mi propia implementación mediante el resumen a una clase, y en ese momento, también podría usar Yo ordeno).