Chi stabilisce DataContext in Silverlight MVVM

Question

ho letto su modello MVVM da varie fonti come MSDN:

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

In quell'articolo si dice: A differenza del presentatore in MVP, un ViewModel non ha bisogno di un riferimento a una vista.

Se la vista (XAML) assume è DataContext è il ViewModel poi dove nel codice è la seguente riga:

view.DataContext = viewModel; 

Il ViewModel non sa nulla circa la vista in modo che non può impostare il DataContext. Se fornisco il ViewModel come riferimento, interrompo il pattern MVVM? La mia altra scelta è di avere un qualche tipo di Builder o Presenter extra il cui unico compito è quello di collegare l'intera cosa (attendere l'evento caricato della Vista, impostare DataContext).

So che le diverse viste possono condividere lo stesso DataContext (ad esempio, imposta DataContext solo per la finestra principale e altre lo vedranno) ma in molti casi ciò non è affatto possibile o addirittura fattibile.

Answer 1

Shawn Wildermuth ha un grande post sul fatto che il Visualizza o ViewModel viene prima: http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model

mi piace, e l'uso, il suo concetto di matrimonio dove una classe 3a parte crea sia la vista e ViewModel, e quindi associa il Due. Ha funzionato bene per me.

Answer 2

Questa è una grande domanda che ha molte risposte. Tutto dipende da come si desidera progettare la propria applicazione. Ad esempio, utilizzo dependency injection per creare il mio IViewModel, che a sua volta crea il mio IView e il mio IViewModel esegue un IView.SetViewModel (questo) sul costruttore.

Altre persone potrebbero voler usare un metodo più blendable impostando il DataContext in XAML:

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

A volte il DataContext può essere implicita per cui è impostato dal quadro, come nel caso di un DataTemplate usato da un ItemsControl. Questo è anche abbastanza comune nel desktop WPF perché supporta DataTemplates digitati.

Quindi non c'è davvero un modo sbagliato per impostare DataContext, basta che ciò che si è separato riguarda, è gestibile ed è anche facilmente verificabile.

Answer 3

Uso MVVM molto con Prism. In Prism uso l'unità per l'iniezione di dipendenza. Quindi ho un'interfaccia per ogni classe registrata con Unity inclusa la Vista. L'interfaccia IView ha un metodo come questo:

void SetViewModel(object viewModel); 

viewmodel chiama questo metodo alla fine del suo costruttore, si passa come parametro:

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

Nel View.xaml.cs la L'interfaccia IView è implementata. Questo sarà l'unico codice aggiungo al codebehind della vista:

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

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

} 

Answer 4

Per quanto riguarda il mio uso, il ViewModel non conosce la vista, o di qualsiasi interfaccia per la vista. E la maggior parte del tempo, la vista non conosce il suo ViewModel, anche se è meno importante. La VM è appena tradotta da DataContext.

Ciò garantisce che VM e V rimarranno altamente indipendenti. I collegamenti sono stabiliti attraverso binding, comandi, comportamenti, trigger & così via. Anche se la VM è spesso altamente correlata a una determinata vista, cerco di renderla il più generica possibile, in modo da poter cambiare la vista corrispondente e/o adattare il comportamento della vista senza dover aggiornare la VM, tranne se il collegamento architettonico tra V e M è interessato!