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

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

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 preferible?

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

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

Esto puede llevar a situaciones en las que la vista es 100% XAML, incluso instanciar 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.

Fuente

2010-07-27 Matt Greer

Me inclino a estar de acuerdo con usted en esto, que si no tiene el tipo de aplicación donde los comandos son ampliamente útiles, entonces realmente no veo lo que le compra el tipeo extra. Como dices, no afecta la capacidad de prueba del modelo de vista de una forma u otra. Algunas personas mantienen la opinión de que una vez que comienzas a tener CUALQUIER código de código subyacente, no serás capaz de detenerte a escondidas en la lógica que debería estar en el modelo de vista. –

La preferencia se debe a la capacidad de prueba, no al marcado xaml/codebehind. Esta pregunta sería realmente interesante si su ejemplo de código tuviera los dos enfoques para probar estas alternativas. es decir, su prueba para ViewModel.SaveChanges() y una prueba basada en ICommand. – itchi

Facilita la prueba unitaria y/o TDD. 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.

Fuente

2010-07-27 15:42:16

¿Cómo? ¿Estás poniendo a prueba tus puntos de vista? Nada de lo que sugiero tiene un impacto real en el modelo de vista, por lo que es igualmente comprobable en ambos escenarios. –

@Matt: La interfaz de comandos ofrece algo más que un evento. – AnthonyWJones

Actualicé mi respuesta ... Una vez que la vista XAML se convierte en solo en la presentación, puede probar la unidad de todo el comportamiento de la presentación, ya que está en el modelo de vista y en los comandos. La corrección visual de las vistas es probada por humanos. –

Probablemente haya muchos argumentos que pueda escuchar, pero pragmáticamente solo hay uno, testabilidad. 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 la que podría lograr si hubiera mantenido el código de la UI más integrado.

No necesariamente lo recomiendo, 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.

Fuente

2010-07-27 15:48:03 AnthonyWJones

Claro, y hago todo eso. Tengo pruebas unitarias completas para todos mis modelos de vista. Siento que me estoy perdiendo algo fundamental aquí. La forma en que la vista vuelve a aparecer en el modelo de vista no parece hacer mucha diferencia en las pruebas. Me pareció que una ventaja de este enfoque es usar IoC para permitirle inyectar datos ficticios y potencialmente diseñar sus vistas en Blend de una manera que se acerque más a su uso real. –

Matt no te falta nada. El uso de un manejador de eventos vs Comando NO afecta la capacidad de prueba. Todos han subido al carro de MVVM y siempre usan Comandos en los ejemplos, incluso cuando a menudo no hay ventajas para muchos escenarios. – Schneider

La principal ventaja que veo con el comando es cuando tiene el doble requisito de ejecutar una acción y validando 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 preocuparnos por los controles en la vista (es decir, tener la lógica que dice "encontrar este control y desactivarlo porque no podemos ejecutarlo ahora") podemos crear un comando y simplemente asegúrese de que puede ejecutar retornos falsos. Esto es comprobable independiente de la vista y una vez que lo ligarlo, la propia unión se encarga de la gestión de propiedad enabled del control.

Fuente

2010-07-27 16:42:28

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

diría que las personas que quieren el código detrás "como libre de código como sea posible" son los que han subido al carro de MVVM sin realmente conseguir 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 utilizar 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 lo que desea es llamar a un método en una prensa de botón hay ninguna gran ventaja de utilizar los comandos en lugar de sólo una llamada 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).

Fuente

2010-07-31 06:37:58 Schneider

Aunque generalmente estoy de acuerdo contigo, creo que hay un valor para mantener el xaml libre de código solo para mantener la separación lo más limpio posible.Aunque a veces las reglas deben romperse, cuando lo haces repetidamente es fácil acostumbrarte a romperlas innecesariamente. – kyoryu

No tener código en "XAML" no tiene NADA que ver con SoC (lo que supongo que quiere decir con "separación limpia"). Si el código se refiere a las responsabilidades de la Vista, entonces no está violando el principio de SoC. – Schneider

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

Respuesta

Cuestiones relacionadas