2010-02-17 11 views
6

En el patrón MVP, un Presentador tiene una interfaz de Vista para que el presentador pueda llamar a iview.DoSomething() ... ¿Qué pasa con el patrón de MVVM?¿Puede un ViewModel hablar con View en el patrón MVVM?

De acuerdo con el diagrama UML http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx de John Gossman, ViewModel no tiene una interfaz de vista. Por lo tanto, parece que el ViewModel y la Vista deben comunicarse solo a través de Binding. (o usar propiedad adjunta o comportamiento de mezcla, etc.).

¿Qué piensan?

+0

Hola Skaffman, gracias ... ¿Qué editaste? :) –

+0

Agregó la etiqueta design-patterns. Verifique el historial de edición haciendo clic en el texto "editado". – stiank81

+0

gracias ... genial ... No vi ese texto "editado" ... Solo veo "editar | revertir | borrar | bandera". de todos modos, gracias por agregar una etiqueta más para mi publicación ... –

Respuesta

5

Estoy de acuerdo con John Gossman. La forma en que ViewModel "habla" con la Vista es solo a través de Vinculaciones. De hecho, ViewModel no debería preocuparse por la Vista en absoluto. Simplemente debe hacer que los datos estén disponibles a través de las propiedades, y depende de la Vista decidir a qué se vinculará dinámicamente en ViewModels. Si el ViewModel quiere decirle a View algo, esto debería ocurrir implícito a través de Bindings.

Una pregunta similar se hizo hace una hora - here.

+0

Muchas gracias. Estoy de acuerdo con eso también. cuando estaba escribiendo esta publicación http: // michaelsync.net/2010/02/03/rules-of-mvvm, algunos dijeron que está bien tener la interfaz de vista en ViewModel. Les dije que sería un patrón de MVP. por supuesto, podemos mezclar los patrones pero creo que tener una interfaz de View en VM viola el patrón de MVVM. Gracias por su respuesta. Realmente lo aprecio. –

+0

Parece que estás en el camino correcto. Me alegra ser de ayuda. Verificará tu publicación de blog! :-) – stiank81

+0

Gracias. por favor, avíseme si tiene algún comentario o sugerencia para esa publicación ... :) –

1

El propósito total de MVVM es reducir enormemente la cantidad de código en su clase de código subyacente de su formulario WPF o control de usuario. La idea es que todo lo que pueda manejar la vista en MVC/MVP clásico se pueda trasladar a la máquina virtual mediante una combinación de enlace de datos y/o comandos. En mi uso general de MVVM, he logrado eliminar por completo todo el código subyacente en mis formularios/controles de usuario y la VM no tiene conocimiento directo de la vista que está controlando. Si tiene una situación que realmente no puede ser manejada mediante el enlace de datos o un comando, por favor elabore su pregunta inicial y yo (o uno de los muchos, muchos más talentosos MVVM aquí) trataré de dirigirlo en la dirección correcta. .

+0

Gracias. La pregunta es ~ ¿Crees que tener una interfaz de View en ViewModel viola el patrón de MVVM? Ejemplo: IPersonView, PersonView y PersonViewModel ... y PersonViewModel tiene IPersonView ... –

+0

Hola, perdí el comentario y nos vemos que aceptaste la respuesta de Stian pero, para completar, esta es mi respuesta. Creo que viola el patrón MVVM (a mi entender) y como ahora mencioné el uso de enlace de datos a través de propiedades expuestas es la forma de actualizar la vista. Me alegro de que hayas recibido una respuesta :) –

+0

Gracias, hombre ... En realidad, tu publicación también me ha respondido, pero el problema aquí es que no puedo marcar más de una publicación como respondida. Como no hay una regla estándar ni propietario/creador para el patrón MVVM, debemos preguntar a todos si todos estamos de acuerdo o no ... :) Por eso estoy haciendo la pregunta sobre MVVM en diferentes comunidades y escribo el información resumida en una de mis publicaciones .. –

1

Normalmente lo hace, a través de eventos en INotifyProperty cambiados, si nada más.

+0

Lo siento. No te entendí ... ¿Estás hablando de tener una interfaz de View en VM? –

+1

Suponiendo que está hablando C#, los eventos expuestos en la interfaz INotifyPropertyChanged suelen ser escuchados (a través del enlace de datos) por la Vista. El enlace de datos no es realmente mágico, es solo conectar manejadores a eventos en INotifyPropertyChanged e INotifyCollectionChanged. Pero sí, yo diría que, por lo general, la máquina virtual habla con la Vista para informarle sobre cambios en los datos. Sin embargo, tiene una idea de una vista * abstracta * y no una implementación en particular: su comunicación debe limitarse a "esto cambiado" y no a "cambiar así este control" – kyoryu

+0

Sí ... Entonces, "esto cambió" la limitación = Datos Encuadernación, ¿verdad? :) –

1

¿Puede un ViewModel hablar con View in MVVM pattern?

Sí, pero de manera desacoplada. Se permite introducir una interfaz IView para la comunicación.

El patrón MVVM está a punto de mover la lógica de la Vista al ViewModel. De esta forma, podemos probar esta lógica en forma unitaria.

+0

Miré a WAF hace mucho tiempo. Vi que el creador de WAF configuró la contraseña en el código en Demo. No estoy seguro de por qué lo hace. >> Sí, pero de forma desacoplada. Entonces, ¿cuáles serían las diferencias entre el patrón MVP y MVVM? También podemos mover la lógica a Presenter en MVP. ¿Cree que está bien establecer iview.DoSomething desde ViewModel? –

+0

Desde el punto de vista del desacoplamiento y la capacidad de prueba, definitivamente se puede llamar a IView.DoSomething desde el ViewModel. Si usa Binding en su lugar, define una propiedad de ViewModel. Entonces, la vista conoce las propiedades de ViewModel. Es solo que Binding usa Reflection (no type safe) pero el acoplamiento es el mismo. – jbe

+0

para el desacoplamiento y la capacidad de prueba, ni siquiera necesitamos usar el patrón MVVM. MVC o MVP o etc. también son verificables. Todavía tengo dos preguntas. 1) Si dijiste que está bien tener una interfaz de Vista en ViewModel. ¿Puedes decirme las diferencias entre MVP o MVVM? También puede leer mi discusión con Glenn en este enlace http://groups.google.com/group/wpf-disciples/browse_thread/thread/7588c66f21fb82af también. 2) ¿Crees que está bien hacerlo ((ViewModel) this.DataContext) .DoThat() también en View? –

Cuestiones relacionadas