¿Quién establece DataContext en Silverlight MVVM

Question

He estado leyendo sobre el patrón MVVM de diversas fuentes como MSDN:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

En ese artículo se dice: A diferencia del presentador de MVP, un modelo de vista no necesita una referencia a una vista.

Si la vista (XAML) asume que es DataContext es el modelo de vista entonces en qué parte del código es la siguiente línea:

view.DataContext = viewModel; 

El modelo de vista no se sabe nada acerca de la vista por lo que no se puede establecer el DataContext. Si le doy a ViewModel la referencia ¿rompo el patrón MVVM? Mi otra opción es tener algún tipo de Creador o Presentador extra cuyo único trabajo es cablear todo (esperar el evento cargado de la Vista, configurar el DataContext).

Sé que las diferentes vistas pueden compartir el mismo DataContext (por ejemplo, establecer el DataContext solo para la ventana principal y otros lo verán) pero en muchos casos eso no es posible en absoluto ni siquiera factible.

Answer 1

Shawn Wildermuth tiene un gran post acerca de si la vista o el modelo de vista es lo primero: http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model

me gusta, y su uso, su concepto matrimonio en el que una clase tercera parte crea tanto la vista y modelo de vista y, a continuación, asocia el dos. Me funcionó bien.

Answer 2

Esta es una gran pregunta que tiene muchas respuestas. Todo depende de cómo quieras diseñar tu aplicación. Por ejemplo, utilizo la inyección de dependencia para crear mi IViewModel, que a su vez crea mi IView y mi IViewModel ejecuta un IView.SetViewModel (this) en el constructor.

Otras personas pueden desear utilizar un método más blendable estableciendo el DataContext en el Xaml:

<UserControl.DataContext> 
    <ns:CrazyViewModel /> 
</UserControl.DataContext> 

veces el DataContext puede ser implícita por lo que se establece por el marco, como en el caso de un DataTemplate utilizado por un ItemsControl. Esto también es bastante común en WPF de escritorio porque admite plantillas de datos tipeadas.

Así que realmente no hay una manera incorrecta de configurar el DataContext, siempre y cuando lo que tiene separe las preocupaciones, se puede mantener y también es fácilmente comprobable.

Answer 3

Uso mucho MVVM con Prism. En Prism utilizo Unity para la inyección de dependencia. Por lo tanto, tengo una interfaz para cada clase registrada con Unity, incluida la Vista. La interfaz IView tiene un método como este:

void SetViewModel(object viewModel); 

El ViewModel llama a este método en el final de su constructor, pasando como un parámetro:

public ViewModel(IView view, ...) 
{ 
    ... 
    this._view=view; 
    this._view.SetViewModel(this); 
} 

En el View.xaml.cs la La interfaz IView está implementada. Este será el único código que se suman a los de código subyacente de la vista:

public partial class View:UserControl, IView 
{ 
    public View() 
    { 
    ... 
    } 

    public SetViewModel(object viewModel) 
    { 
    this.DataContext = viewModel; 
    } 

} 

Answer 4

En cuanto a mi propio uso, el modelo de vista no conoce la vista, o cualquier interfaz en la vista. Y la mayoría de las veces, la Vista no conoce su ViewModel, incluso si es menos importante. La máquina virtual acaba de ser transferida por el DataContext.

Esto asegura que la máquina virtual y la unidad virtual seguirán siendo muy independientes. Los enlaces se establecen a través de enlaces, comandos, Comportamientos, Activadores & y así sucesivamente. Incluso si VM a menudo está muy relacionado con una vista determinada, trato de hacerlo lo más genérico posible, de modo que pueda cambiar la Vista correspondiente y/o adaptar el comportamiento de la Vista sin necesidad de actualizar la VM, excepto si el enlace arquitectónico ¡entre V y M se ve afectado!