MVVM Verständnisfragen

Hallo Community,

ich hab das MVVM Pattern noch nicht ganz verstanden, so denke ich.

Beim "Model View - View - Model" Pattern bau ich doch meine App, oder in Silverlight meine Page aus folgenden Objekten auf.

 [color]MODELVIEW -> Die Klassee die die Binding zu verfügung stellt[/COLOR]

 [color]VIEW -> in Silverlight die in Xaml Beschriebene Oberfläche[/COLOR]

 [color]Model -> Code Behind (Logik)[/COLOR]

Ich hoffe das hab ich soweit richtig verstanden.
Die Bindin werden doch dann folgendermaßen gesetzt... die View bindet sich an die ModelView und die ModelView an das Model, per "twoWay-binding"?

Weitere Fragen beziehen sich auf die ModelView Klasse.
Wie verwende ich das in der Praxis?
Mir werden die BeispielCodes die ich im Internet gefunden habe nicht ganz klar, z.B. folgender hier, wo passiert hier denn das Binding?

MVVM for Tarded Folks Like Me or MVVM and What it Means to Me

Es würde mir auch schon stark wenn mir hier einer von euch eine einles lektüre verlinken kann, am besten irgendwas im Web, ich möchte nur ein Grundverständnis erstmal dafür haben und mir nicht wieder einen Schinken von Buch kaufen über ein Thema.

schonmal danke fürs durchlesen.

gruß ScoobyDoh!

Hallo,

schau mal in Using the MVVM Pattern in Silverlight Applications

Auch könnte ich dir die Video2Brain DVD "WPF 4 & Silverlight 4" von Gregor Biswanger ans Herz legen.
Sehr gut! Meiner Meinung nach besser als ein Buch, da man direkt alles live sieht und sehr gut erklärt wird.

Aber wirklich ganz verstanden habe ich das mit MVVM auch noch nicht, da es so scheint das es jeder irgendwie anders macht und es nicht nur einen Weg gibt.

Hallo ScoobyDoh!,

Ich hoffe das hab ich soweit richtig verstanden.

Nicht ganz: Du hast Model, View und ViewModel.

die View bindet sich an die ModelView und die ModelView an das Model, per "twoWay-binding"?

Der erste Teil des Satzes stimmt so, der zweite nicht unbedingt:
Während das ViewModel die Struktur des UIs so ziemlich 1:1 widerspiegelt (d.h. hierarchische Daten im UI sind auch im ViewModel hierarchisch; wenn sich in einem View zwei Textboxen und ein Button befinden, hat auch das zugehörige ViewModel zwei Properties vom Typ string und eine vom Typ ICommand; etc.), können zwischen Model und ViewModel durchaus größere Unterschiede bestehen. Das Model muss noch nicht einmal an das ViewModel gebunden sein.
Das ViewModel ist dabei sehr "UI-Freundlich", d.h. es stellt alles so bereit, dass das View keine Converter mehr benötigt - im Klartext also: Alle Properties des ViewModels sind im Normalfall vom Typ string, ICommand oder einem anderen ViewModel-Typ.
Kommunikation zwischen View und ViewModel erfolgt ausschließlich über Commands, Binding und Events (allen voran PropertyChanged).

Letzlich "kennt" lediglich das ViewModel das Model (im View ist es meist unbekannt); das ViewModel ist hingegen im View unbekannt und das ViewModel hat keinen direkten Zugriff auf das View (wurde aber mit Blick auf dessen Aufbau designt).

In sehr einfachen Anwendungen / Szenarien kann das Model auch mal wegfallen.

Siehe generell auch Artikel und Beispiel zu Model-View-ViewModel mit WPF

Mir werden die BeispielCodes die ich im Internet gefunden habe nicht ganz klar, z.B. folgender hier, wo passiert hier denn das Binding?

An sich nur in der einen Zeile:

<TextBlock Text="{Binding Name}" />

Damit es jedoch funktioniert, muss das ViewModel INotifyPropertyChanged implementieren.

Vielen danke euch beiden.

Im Silverlight Kontext heisst das dann,

View = XAML Definition mit den Bindings an Properties die in dem ViewModel hängen. Das würde ja auch bedeuten, das mein ViewModel die CodeBehind Datei meiner View ist.

Das ViewModel greift dann gerade auf meine Logik zu, oder dessen Struktur die ich in Klassen abarbeite.

In dem ViewModel erstell ich mir dann eine Instanz meines Objekts und über dessen Instanznamen greif ich auf die Properties zu, denen ich dann noch das Binding im C# erlaube.

Ich glaub ich habs verstanden.

Bin in der ganzen Geschichte noch etwas neu. ^^

Aber vielen dank schonmal.

gruß ScoobyDoh!

das mein ViewModel die CodeBehind Datei meiner View ist.

Nein, eher nicht.
Im Normalfall versucht man in einer MVVM-Anwendung, diese Codebehind-Datei möglichst leer zu halten. Die ViewModel-Klassen sind folglich wirklich eigenständige Klassen (die nicht von Control oder DependencyObject erben).
Dadurch trennt man dann Daten/Verhalten auch codetechnisch von deren Darstellung.

Ah ok,
ja dann kann ich ja im Normalfall die CodeBehind eh leer lassen.

Wird aber in meinem Fall (Windows Phone 7) vielleicht ein bisschen anders funktionieren, ich brauch ja eine Datei die von "PhoneApplicationPage" erbt, hier trigger ich ja meine Usereingabe in den Events ab. Wie hier auch auf die Rotation des Smartphones reagiere, wenn der User das Phone schräg/waagrecht hält.

Als praktische Umsetzung des MVVM-Pattern, oder zumindest dieses teilweise zu erfüllen würd ich das folgendermaßen Umsetzen,

View - XAML

ViewModel - bereitstellen der Converter sowie den Properties für das Databinding

Codebehind - reagieren auf die Events der Usereingaben
-> Model - Logik

View - XAML

Ja.

ViewModel - bereitstellen der Converter sowie den Properties für das Databinding

Jein - ein ViewModel stellt keine Konverter bereit; es ist vielmehr selbst eine Art Konverter (hat aber nichts mit IConverter zu tun!).

Codebehind - reagieren auf die Events der Usereingaben
-> Model - Logik

Auf jeden Fall sollte es die Events an das ViewModel weiterleiten - das entscheidet dann, inwieweit das Model überhaupt irgendwie verwendet wird.

Beispiel (für ein einfachen One-Way-Chat 😉 ):1.Der Benutzer gibt etwas in eine Textbox ein; der Wert wird via Binding in das ViewModel übertragen, z.B. an die "Message" Property 1.Der Benutzer drückt auf "Senden"; das ViewModel wird darüber über ein Command informiert (genauer gesagt stellt das ViewModel eine Property vom Typ ICommand bereit, an die der Button gebunden ist). 1.Das ViewModel prüft jetzt, ob seine eigene "Message"-Property leer ist (die ja durch das View via DataBinding in Schritt 1 gefüllt wurde).
Wenn ja, unternimmt es nichts weiter (oder gibt vielleicht etwas in einer Messagebox aus oder wie auch immer) - ansonsten geht's weiter:

1.Das ViewModel übergibt nun an das Model, in dem es IChat.SendMessage (den IChat hat es im Konstruktor übergeben bekommen) aufruft. Als Parameter übergibt es den Wert von Message

Somit kümmert sich das View um das Entgegennehmen von Benutzereingaben und die Weiterleitung an das ViewModel (im Normalfall geht das rein via XAML).
Das ViewModel verarbeitet diese Benutzereingaben, delegiert aber Aufgaben (z.B. "Nachricht senden") an das Model weiter
Das Model hingegen hat nichts mit der konkreten Benutzeroberfläche zu tun - in diesem Beispiel ist es für die Zustellung der Nachricht (z.B. via Webservice) verantwortlich.

//EDIT:
Die Schnittstellen von ViewModel und Model sehen wie folgt aus:

//Model:
public interface IChat
{
   public void SendMessage(string message);
}

//ViewModel (muss nicht unbedingt ähnlich wie das Model heißen - könnte durchaus auch mehrere Models verwenden):
public interface IChatViewModel
{
   public string Message { get; set; }
   public ICommand SendCommand { get; }
}

Zu winSharp93 Beitrag ergänze ich noch folgendes Stichwort
EventToCommand

Hallo, ich meld mich nochmal zurück,

ich wollte nun das MVVM Pattern umsetzen, nun hab ich dazu noch eine Frage,
und zwar kann man ein ViewModel für mehrere Views benutzen.

nehmen wir an, ich hab eine KOntaktliste, wo ich auf meiner MainPage eine übersicht habe, hier bekomm ich ein Bild, Vorname und Nachname angezeigt.
Auf einer DetailsPage, möchte ich aber mehr Information von einem Kontakt anzeigen lassen, entspricht es da dem MVVM Pattern, das ich für mehrere Views mich an ein ViewModel binde?

gruß ScoobyDoh!

Das ist kein Problem.

Solange beide Views vom selben handeln können sie sich meiner Meinung nach ohne Probleme das selbe ViewModel teilen.

Was anderes ists aber wenn eine view nur zum anzeigen und zum Auflisten von zB Personen ist und eine andere View zum Editieren einer Person verwendet wird. Hier würd ich trennen weil es unterschiedliche Aufgaben sind die dann in einem ViewModel vermischt wären.

Lg XXX

Meiner Meinung nach (Muss nicht Richtig sein) sollte jede View ihr eigenes ViewModel
haben.
Wenn die Kommunikation zwischen den VMs erforderlich ist dann solltest du dir mal
Prism anschauen oder falls das Over Kill ist mit Statischen Events (oder Properties in
der BasisKlasse) arbeiten

wie gesagt:
Meine Meinung (muss nicht Richtig sein!)

Meiner Meinung nach (Muss nicht Richtig sein) sollte jede View ihr eigenes ViewModel
...

Soviel wie ich jetz davon gelsen hab, ist das MVVM Pattern eh auslegungssache, in vieler hinsicht. Jeder spricht ja nur von seiner Interpretation von MVVM, ein allgemeingültige "NORM" gibt es ja nicht.

Deswegen ist deine Meinung immer gern gehört 😄

Vielen dank für eure Antworten ich probier das mal jetzt aus, aber ein einfaches Beispiel mit wenig Code im Web gibt es nicht, oder?
Finde nämlich nur overkill bespiele^^

gruß ScoobyDoh!

Ich kann dir Dieses WebCast empfehlen

Silverlight in Deep

Ist zwar Silverlight aber in WPF ist es das gleiche Prinzip

ich schaff ja auch mit Silverlight, daher genau richtig 😉

vielen dank.

OH, sogar noch in Deutsch, wahnsinn, bis jetz noch nicht gefunden, super Sache und vielen dank.

Eine Frage hätte ich noch, warum hast du in folgenden Beispiel das Model und das ViewModel als Interface deklariert?

...
//EDIT:
Die Schnittstellen von ViewModel und Model sehen wie folgt aus:

  
//Model:  
public interface IChat  
{  
   public void SendMessage(string message);  
}  
  
//ViewModel (muss nicht unbedingt ähnlich wie das Model heißen - könnte durchaus auch mehrere Models verwenden):  
public interface IChatViewModel  
{  
   public string Message { get; set; }  
   public ICommand SendCommand { get; }  
}  
  
  

Um eine losere Kopplung zu erreichen und aus Gründen der Testbarkeit. Siehe dazu auch T(est)D(riven)D(evelopment).

Lg XXX

Wenn du mehr wissen willst dann guckst du hier (Behandelt in erster linie zwar das Framework Prism aber dort wird auch gezeigt und erklärt wieso Klassen Interfaces verwenden sollten)

prism--silverlight-part-1-taking-sketched-code-towards-unity

leider english aber es lohnt sich!

Danke für eure Antworten,

aber irgendwie hab ich das noch net kapiert, oder kann es nicht auf meine belange abstrahieren.

Ich hab folgendes Problem,
ich hab mehrere Silverlight Pages in meiner App, auf diesen Pages ist eine wiederholung der gleichen UI Elemente zu sehen, in meinem Fall sind das Canvas('es?) .

Zuerst dacht ich ich schreib mir eine Silverlight style class und übergebe damit dann eben die Properties.

Nun möchte ich einen Brush im Code behind erzeugen, also zwei. Und wenn ich nun meinen bool HintergrundRot habe, dieser auf true ist soll sich das Canvas rot färben, über alle Pages hinweg und wenn nicht dann eben blau.

Nun wollt ich im ViewModel mir zwei Brushes definieren im Model meine Variable HintergrundRot, und in der View mein Canvas das per Binding mit dem ViewModel verbunden ist über die Propertie "Background".

Nur find ich jetz gar keinen Ansatz, wie ich das nun bewerkstellige.

Ich will mich da jetzt nicht in die Nesseln setzen, aber für mich wären solche Sachen die Du da machen möchtest in der VIEW oben.

Das MVVM Pattern sieht ja vor die UI mit dem Rest mittels Vermittler (ViewModel) zusammen zubringen ohne dass diese von einander was wissen.

Canvas etc. sehe ich nicht als Bestandteil, dass man im MVVM verwenden sollte hierfür müsstest Du dir ja entsprechende UserControls machen und auch die Styles dementsprechend dort oder in einem ResourceDictionary definieren.

Hier ist eine nette Diskussion zu dem Thema: Pros and cons of having a WPF specifics in the view model

Prinzipiell ist es Aufgabe der View sich um das Aussehen also auch um die Farben zu kümmern. Wenn es nicht unbedingt eine Farbe ist, die der User zur Lauftzeit selbst bestimmen kann sehe ich auch keinen Grund die Farben im ViewModel oder gar im Model zu definieren. Wenn es nur ein bestimmtes Set an verschiedenen Farben gibt, sollte die View nur die Information bekommen welches "Schema" oder "Style" gerade aktiviert ist und die View entscheidet dann anhand von Triggern usw. welche Farbe dafür zu verwenden ist.

Lg XXX

...
Wenn es nur ein bestimmtes Set an verschiedenen Farben gibt, sollte die View nur die Information bekommen welches "Schema" oder "Style" gerade aktiviert ist und die View entscheidet dann anhand von Triggern usw. welche Farbe dafür zu verwenden ist.

Lg XXX

Das hab ich soweit begriffen und ist auch nachvollziehbar.
Aber da ich auf dem WP7 schaff und eine App dort mal schnell über 10 Seiten haben kann, ist es mehr arbeit in jede View von jeder Seite die Klassen reinzuschreiben, dann spar ich mir gar nichts und machs mir nur noch unübersichtlicher, das wollte ich eigentlich mit dem MVVM umgehen.

Aber hab nun keine Idee wie.^^

Styles kann man auslagern? Entweder in externe ResourceDictionaries die man einbindet oder in die App.xaml. Ich style prinzipiell 90% meine App in einem ResourceDictionary, welches ich zur Laufzeit in der App.xaml einbinde und style nur in Ausnahmefällen in den einzelnen Views.

Lg XXX

Styles kann man auslagern?

Das wär mein erster Ansatz gewesen, aber das geht ja nicht.

Entweder in externe ResourceDictionaries die man einbindet oder in die App.xaml. Ich style prinzipiell 90% meine App in einem ResourceDictionary, welches ich zur Laufzeit in der App.xaml einbinde und style nur in Ausnahmefällen in den einzelnen Views.

Aha hört sich sehr interessant an.
Kannst du dann auch in Expression Blend designen? Oder schließt sich das mit der Methode aus?

danke für deine Antwort

gruß ScoobyDoh!

Das wär mein erster Ansatz gewesen, aber das geht ja nicht.

Und was geht nicht?
Ich habe selber ein Silverlight Projekt in dem alle Styles in ein eigenes Projekt
ausgelagert worden sind. Im Designer sehe ich den Style dann zwar nicht aber zur Laufzeit

Und was geht nicht?
Ich habe selber ein Silverlight Projekt in dem alle Styles in ein eigenes Projekt
ausgelagert worden sind. Im Designer sehe ich den Style dann zwar nicht aber zur Laufzeit

Also geht doch... ^^
Gut wie hast du denn das bewerkstelligt? Würde mir bei meinem Problem jetzt stark helfen, dann könnte ich für mehrere Seiten die gleichstarke Identität zu der Logik haben ein ViewModel benutzen, das hoff ich zumindest.^^

Ich habe ein neues Projekt erstellt (ClassLibrary)
Danach ein ResourceDictionary angelegt (Styles.xaml)

In der View habe ich dann folgendes als Resource definiert:

<UserControl.Resources>
        <ResourceDictionary x:Key="CustomStyles">
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/MyClassLib.Styles;component/Styles.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
</UserControl.Resources>

Natürlich den Verweis auf die ClassLib nicht vergessen

Coole Sache,
werd ich mal probieren.

Jedoch bin ich dann von der verwendung des MVVM net schlauer geworden, was kann denn ein Designer anfangen, wenn er die Styles nicht sieht und immer kompilieren müsste.

Für meine Zwecke jetzt, vollkommend ausreichend, aber ich denk nicht das das die Bahnbrechende Lösung ist, oder doch?

Vielen dank schonmal ProGamer!

Ganz klar wird mir die Notation hier nicht,

Source="/MyClassLib.Styles;component/Styles.xaml"

Was ist nun die MyClassLib? Und warum darauf die Referenz?
Die Styles befinden isch aber in der Styles.xaml, oder?

Bevor man die Styles auslagert kann man sie auch direkt in den Resourcen der View definieren. Der Designer würde den Style immer anzeigen Ohne kompilieren zu müssen

Ganz klar wird mir die Notation hier nicht,

Source="/MyClassLib.Styles;component/Styles.xaml"  

Was ist nun die MyClassLib? Und warum darauf die Referenz?
Die Styles befinden isch aber in der Styles.xaml, oder?

MyClassLib.Styles ist der Name des Projektes. Das "MyClassLib.Styles;component" gibt an dass sich die Datei innerhalb einer anderen Assembly befindet. ohen das wird innerhalb der eigenen Assembly gesucht und logischerweise nichts gefunden

Bevor man die Styles auslagert kann man sie auch direkt in den Resourcen der View definieren. Der Designer würde den Style immer anzeigen Ohne kompilieren zu müssen

Um die Usability zu steigern hab ich allerdings vor Seite für Seite in meiner App gleich aussehen zu lassen, da wären "globale" klassen stark vom Vorteil.

Mir auch unverständlich warum es sowas nicht gibt, ich hab das jetzt einfach vorrausgesetzt^^

Um die Usability zu steigern hab ich allerdings vor Seite für Seite in meiner App gleich aussehen zu lassen, da wären "globale" klassen stark vom Vorteil.

verstehe ich nicht ganz. mit der Style Klasse kannst du doch mit jeder View auf die Styles zugreifen oder geht es dir darum diese auch Sofort im Designer zu sehen?
Wenn ja dann definiere die Styles im selben Projekt

Um die Usability zu steigern hab ich allerdings vor Seite für Seite in meiner App gleich aussehen zu lassen, da wären "globale" klassen stark vom Vorteil.

verstehe ich nicht ganz. mit der Style Klasse kannst du doch mit jeder View auf die Styles zugreifen oder geht es dir darum diese auch Sofort im Designer zu sehen?
Wenn ja dann definiere die Styles im selben Projekt

1. Ja Genau darum geht es mir 😉

2. Dann werd ich das so machen, vielen dank für den Tippo ^^