2009-09-01 1 views
9

ich über MVVM Muster aus verschiedenen Quellen wie MSDN gelesen habe:Wer Datacontext in Silverlight MVVM setzt

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

In diesem Artikel heißt es: Im Gegensatz zu den Presenter in MVP, ein Ansichtsmodell nicht eine Notwendigkeit Referenz auf eine Ansicht.

Wenn die View (XAML) geht davon aus, es ist Datacontext das Ansichtsmodell ist dann in dem Code, in dem die folgende Zeile:

view.DataContext = viewModel; 

Das Ansichtsmodell nichts über die Aussicht nicht kennt, so dass es nicht die Datacontext festlegen. Wenn ich dem ViewModel die Referenz gebe, zerbrich ich das MVVM-Muster? Meine andere Wahl ist eine Art Builder oder extra Presenter, dessen einzige Aufgabe es ist, die ganze Sache zu verkabeln (warten Sie auf das geladene Ereignis der Ansicht, setzen Sie den DataContext).

Ich weiß, dass verschiedene Ansichten den gleichen DataContext teilen können (z. B. den DataContext nur für das Hauptfenster einstellen und andere sehen ihn), aber in vielen Fällen ist das überhaupt nicht möglich oder gar machbar.

Antwort

3

Shawn Wildermuth hat einen großen Beitrag darüber, ob die Anzeigen oder Ansichtsmodell kommt zuerst: http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model

Ich mag, und zu verwenden, seine Ehe Konzept, bei dem eine 3rd-Party-Klasse sowohl die Ansicht und Ansichtsmodell erstellt, und ordnet dann die zwei. Es hat gut für mich funktioniert.

6

Dies ist eine gute Frage, die viele Antworten hat. Alles hängt davon ab, wie Sie Ihre Anwendung erstellen möchten. Zum Beispiel verwende ich Dependency Injection, um mein IViewModel zu erstellen, das wiederum mein IView erstellt, und mein IViewModel führt ein IView.SetViewModel (this) für den Konstruktor aus.

Andere Leute wünschen kann eine mischbare Methode verwenden, indem Sie die Datacontext in der XAML-Einstellung:

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

Manchmal kann die Datacontext so impliziert werden sie durch den Rahmen, wie im Fall eines Datatemplate gesetzt Wird von einem ItemsControl verwendet. Dies ist auch in Desktop-WPF ziemlich üblich, da es typisierte DataTemplates unterstützt.

So gibt es wirklich keinen falschen Weg, um den DataContext zu setzen, nur so lange wie das, was Sie haben, Probleme trennt, wartbar und auch leicht testbar ist.

0

Ich benutze MVVM viel mit Prism. In Prism verwende ich Unity zur Abhängigkeitsinjektion. Daher habe ich eine Schnittstelle für jede Klasse, die bei Unity registriert ist, einschließlich der Ansicht. IView Die Schnittstelle hat eine Methode wie folgt:

void SetViewModel(object viewModel); 

Das Ansichtsmodell ruft diese Methode am Ende seines Konstruktors selbst als Parameter:

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

Im View.xaml.cs der IView-Schnittstelle ist implementiert. Dies wird der einzige Code, die ich auf den Code-Behind der Ansicht hinzufügen:

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

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

} 
0

Was meine eigene Nutzung, das Ansichtsmodell kennt nicht die Ansicht, oder jede Schnittstelle auf der Ansicht. Und die View kennt das ViewModel meistens nicht, auch wenn es weniger wichtig ist. Die VM wird nur vom DataContext übertragen.

Dies stellt sicher, dass die VM und V hochgradig unabhängig bleiben. Links werden durch Bindings, Commanding, Behaviors, Trigger & usw. hergestellt. Selbst wenn VM oft stark mit einer bestimmten Ansicht verwandt ist, versuche ich es so allgemein wie möglich zu machen, so dass ich die entsprechende Ansicht wechseln und/oder das Ansichtsverhalten anpassen kann, ohne die VM aktualisieren zu müssen, außer wenn die Architekturverbindung zwischen V und M ist betroffen!