2009-05-13 11 views
21

entiendo que en MVVM:En MVVM, ¿cuál es la mejor manera para que ViewModel responda a las acciones del usuario en la Vista?

  • la vista sabe sobre el modelo de vista
  • el modelo de vista que recibe información del modelo
  • pero no funciona hacia arriba, por lo que el modelo no sabe nada sobre el modelo de vista
  • y el modelo de vista no sabe nada de la vista

Así ¿cómo responde el modelo de vista a las acciones que el usuario realiza en la vista, p. escribir algo en un cuadro de texto o mover un control deslizante, etc.

  1. entiendo que esto se hace con RoutedEvents pero casi todos los ejemplos RoutedEvent I Use CodeBehind en la vista, que es exactamente lo que no lo hace tener más en MVVM.

  2. De modo que deja RoutedCommands que encuentro más ejemplos en MVVM pero p. mover un control deslizante realmente no es un comando en ese sentido, es un evento, así que me pregunto si esto es realmente lo que debería usarse.

  3. Entonces read advice como "En MVVM RoutedEvents usar la menor cantidad posible, y no hay RoutedCommands en absoluto." OK.

  4. Así que eso deja, p. en el proyecto WPF Model-View-ViewModel Toolkit 0.1 del equipo WPF tienen un "DelegateCommand" que también parece una forma interesante.

  5. Entonces algunas personas también están utilizando "RelayCommand".

Esta es una gran cantidad de opciones y confusión para hacer algo tan esencial para el desarrollo de aplicaciones.

Cuál es la mejor manera de hacer simplemente en MVVM lo que estábamos haciendo durante los últimos 10 años con código subyacente de:

  • crear botón
  • botón haga doble clic en el código de manejo
  • escritura

Respuesta

11

Para que quede claro, cuando la gente menciona DelegateCommand y RelayCommand, que realmente están hablando de la misma cosa: una implementación de ICommand que le permite pasar de un delegado. Puedes usarlos de manera intercambiable.

Por lo que a mí respecta, tener su vista (XAML) vinculada a DelegateCommands en ViewModel es la mejor manera de implementar MVVM.

Me mantengo alejado de RoutedEvents AND code-behind siempre que sea posible.

+2

Esto es esclarecedor, gracias. Lo primero que le dicen los libros sobre WPF es cuánto mejor RoutedEvents y RoutedCommands que en WinForms (pueden hacer un túnel hacia abajo y subir el árbol, etc.) así que supuse que así era como se hacía todo en MVVM. Es interesante saber que, aunque RoutedEvents y RoutedCommands son tan nuevos y mejorados, todavía no son útiles para escribir aplicaciones desacopladas. –

+3

Eso es correcto, en mi opinión. El patrón MVVM se está volviendo tan popular porque los RoutedEvents y RoutedCommands (y otras funciones de UI) son muy pesados. Si desea escribir clases desacopladas y comprobables que encapsulen su lógica de vista, debe desacoplarlas de la vista. MVVM realmente brilla con esto, siempre y cuando vea lo que dicen los libros de WPF y Silverlight como una visión obsoleta del desarrollo en este entorno. –

6

Para botones y otros factores desencadenantes utilizo la interfaz de ICommand proporcionada por WPF de forma similar a DelegateCommand que ha vinculado a. (en realidad uso un comando de relé como se define here)

Cuando está cambiando un valor (moviendo un control deslizante, escribiendo en un cuadro de texto) use enlaces y maneje el comportamiento cuando se establece la propiedad en ViewModel.

En general, creo que hay muy pocas razones para usar RoutedEvents en una aplicación MVVM, pero son una cómoda y familiar cobija cuando no puede lograr lo que desea a través de los nuevos métodos específicos de WPF.

Cuestiones relacionadas