silverlight - commandmanager wpf example

¿Cuál es la verdadera ventaja de mantener el código fuera del código XAML?

Question

Hay un gran esfuerzo en la comunidad de Silverlight para mantener el código de XAML detrás del archivo lo más libre posible de código. ¿Cuál es la verdadera motivación detrás de esto?

Por ejemplo, ¿cuál es la ventaja de utilizar un comando en lugar de un controlador de eventos? Si tengo

<Button x:Name="SaveButton" Content="Save" Click="SaveButton_Click" />

...

private void SaveButton_Click(object sender, RoutedEventArgs e) {
    _myViewModel.SaveChanges();
}

Entonces, ¿por qué es esto preferido?

<Button x:Name="SaveButton" Content="Save" Command="{Binding SaveCommand}" />

Donde obviamente SaveCommand en mi modelo de vista va a invocar SaveChanges() .

Esto puede conducir a situaciones en las que la vista es 100% XAML, incluso al ejemplificar el modelo de vista en XAML, y las conexiones entre la vista y el modelo de vista se realizan completamente mediante el enlace. Claro que está limpio, pero ¿qué más es? ¿Flexible? ¿Por qué? la vista aún necesita trabajar con el ViewModel adecuado, de modo que si la conexión entre los dos existe y está implícita, ¿por qué no hacerlo más explícito? También tiene la desventaja de perder soporte en tiempo de compilación. Si conecto mi botón a un controlador de eventos que no existe, el compilador me lo dirá. No lo hará si me enlace a un comando inexistente.

Answer 1

Hay un gran esfuerzo en la comunidad de Silverlight para mantener el código de XAML detrás del archivo lo más libre posible de código. ¿Cuál es la verdadera motivación detrás de esto?

Yo diría que las personas que quieren que el código "sea lo más libre de códigos posible" son aquellos que se subieron al carro de MVVM sin entender realmente el punto. (O eso o has malinterpretado su punto).

El objetivo no es mantener el código libre de código, sino asegurarse de que la Vista solo sea responsable de la presentación visual. El hecho de que muchos aspectos visuales se pueden definir de manera declarativa significa que hay menos código en el código subyacente, pero eso no significa que deba dudar en escribir el código subyacente donde lo considere necesario y que no transgreda fuera de las responsabilidades de la vista.

¿Cuál es la ventaja de usar un comando en lugar de un controlador de eventos?

Un comando ofrece al menos dos capacidades que un controlador de eventos no tiene. Algunos controles WPF conocen la propiedad CanExecute del comando, por lo que un botón se puede deshabilitar cuando el comando no está disponible para ejecutarse. Además, el diseñador y el marco vinculante son conscientes de los comandos.

Si solo desea llamar a un método con un botón, no hay una gran ventaja en el uso de Comandos en lugar de simplemente llamar al método desde un controlador de eventos. Así que no temas utilizar este enfoque. (Un tercer enfoque, que favorece al diseñador sobre el programador, es usar CallMethodAction de Blend 4).

Answer 2

Hace las pruebas unitarias y / o TDD más fáciles. Al usar MVVM y commanding, básicamente puedo construir mi modelo de vista y comandos del estilo TDD y tener la mayor parte de la lógica de vista probada sin tener realmente la vista XAML.

Answer 3

La principal ventaja que veo con el comando es cuando tienes el requisito doble de ejecutar una acción y validar que la acción se puede ejecutar (es decir, el contexto). En otras palabras, si simplemente está vinculando el clic con una llamada a método directo, estoy de acuerdo, tampoco veo ninguna ventaja. Sin embargo, si el clic debe estar condicionado y el botón está deshabilitado en función del contexto, el enlace lo facilita a través de la propiedad CanExecute.

De esta manera, en lugar de tener que preocuparse por los controles en la vista (es decir, tener la lógica que dice "encontrar este control y configurarlo en deshabilitado porque no podemos ejecutarlo ahora mismo") podemos crear un comando y simplemente asegurarnos de que pueda execute devuelve false. Esto se puede probar independientemente de la vista y, una vez que lo vincula, el enlace se ocupa de gestionar la propiedad habilitada del control.

Answer 4

Probablemente haya muchos argumentos que pueda escuchar, pero pragmáticamente solo hay uno, la capacidad de prueba . Un ViewModel ofrece poco a menos que crees una prueba unitaria para él, lo que a su vez implica que necesitarías crear ViewModel de tal manera que puedas probarlo en unidades, usando técnicas como inyección de dependencia, IoC, blah, blah, etc. , etc.

El resultado es que las pruebas unitarias pueden cubrir una parte más grande del código de sus aplicaciones de lo que podría lograr si hubiera mantenido el código de la interfaz de usuario más integrado.

No necesariamente lo estoy recomendando, hacerlo correctamente requiere un considerable esfuerzo de diseño y previsión. Por lo tanto, los costos en la construcción de un enfoque de este tipo son bastante altos, sin embargo, los ahorros de la mayor calidad pueden compensar esos costos.