MVVM - richtig verstanden?

Hallo,

ich habe eine Frage zu dem MVVM-Pattern. Und zwar wird dieses ja quasi als Nachfolger von MVC für WPF gehandelt. Ich habe nun auch einiges zum MVVM-Pattern gelesen, bin mir aber nicht so sicher, ob ich es richtig verstanden habe.

Deswegen meine Frage, ob mir jemand bestätigen kann, dass folgendes Verständnis richtig ist? Und wenn nicht, der mich auf Denkfehler hinweisen kann? Also:

MVVM steht für Model, View, ViewModel. Das Model macht genau das, wie früher auch, Daten bereitstellen. Wenn man so will, stellt das Model die Businessentities zur Verfügung. Wird bei MVVM in C# geschrieben.

Die View stellt die UI dar, die in XAML geschrieben ist, und die absolut keine Logik mehr enthält. Nur die reinen Masken.

Das ViewModel wird zwischen View und Model gesetzt, und repräsentiert den Zustand der UI und der Daten. Wenn ich also beispielsweise eine Maske habe, in der eine Liste von Benutzern angezeigt wird, und außerdem die Daten des ausgewählten Benutzers noch mal extra, dann muss mein ViewModel all diese Daten bereitstellen, so dass sie per DataBinding an das UI gebunden werden können. Auch das Reagieren auf Eingaben übernimmt das ViewModel und leitet es gegebenenfalls an die Businesslogik weiter.

Und zu guter letzt - ich brauche für jede View ein eigenes ViewModel, da es ja abhängig von der konkreten UI ist.

Wenn man also will, könnte man sagen: ViewModel und View sind im Prinzip zusammen "eins", wobei das eine halt aus Code-, das andere aus Designsicht draufschaut.

Richtig so?

Viele Grüße,

Golo

Was Du beschreibst ist nichts andres als ein Passiv View, und genau das ist MVVM
eigentlich auch.

Ein möglichst dummer UI-Teil, damit man ihn durch den ModelView ( Presenter/Controler )
einfach verwalten und ggf austauschen kann.

Okay, danke schön 🙂

Kann es sein, dass sich da XAML im Grunde wie ein HTML GUI (ASP.NET) verhält:

Model - Presentation - UI

?

kaepten

Hmmmm ... sofern Du im HTML kein JavaScript für Logik einbindest, und wenn man mal vom DataBinding absieht, IMHO ja.

Stimmt, JS habe ich ganz ausser Acht gelassen.

Hi alle,

auch wenn der Startbeitrag schon sehr lange zurück liegt, würde ich gerne die Diskussion nocheinmal anstoßen.
Ich beschäftige mich auch zur Zeit etwas mit MVVM und gehe zur Zeit einige Beispiele durch.

Also wie ich das sehe, ist in der VIEW schon auch Logik drin. Aber keine die irgendwas mit der BL zu tun hat, sondern nur die Logik die sich auf die VIEW/Interaktion an sich bezieht. Also z.B. Drag/Drop-funktionalität oder Multimodalität(also z.B. Sound oder Spracheausgabe/(steuerung)).

Ich halte WPF und MVVM für die zukünftige Gestaltungsgrundlage für UIs in Net. Ich würde gerne das auch näher im Zusammenhang mit einem Microkernelframework und Asynchroner Architektur betrachten. Komme leider nicht so viel dazu, dass selbst mal auszuprobieren. Da Softwareentwicklung für mich bis jetzt eher ein Hobby ist. Ich habe also noch nicht das ganze im Überblick.
Kennt jemand gute Beiträge zu dem Thema?

Gut fande ich:An Hand eines Beispiels
oder auch ganz nett:ein kleiner Einblick und Bewertung

Gruß Timo

Das beste Beispiel hierfür bekommst du mit "Composite Application Guidance for WPF and Silverlight"

Hat alles was Du brauchst.
Generische Schnittstelle zu IOC Containern, MVVP.....

Danke, für deine Antwort und den Tip! Werd das Beispiel mal unter die Lupe nehmen!

Gruß Timo

Ich hab das MVVM-Pattern glaub ich auch noch nicht ganz so verstanden, kann mir jemand vll sagen, ob folgendes Beispiel dafür (halbwegs) Richtig ist:

Das Model ist praktisch die TreeViewData-Klasse mit allen Daten (z.B. Name, Alter)
Das ViewModel ist die TreeViewItem-Klasse mit Properties für IsExpanded, IsSelected, ...
Und das View ist dann praktisch das ItemTemplate dafür.

Hallo t-master,

Das Model ist praktisch die TreeViewData-Klasse mit allen Daten (z.B. Name, Alter)

Was meinst du mit TreeViewData?
Unter einer Modelklasse verstehe ich z.B. eine Klasse Person.

Das ViewModel ist die TreeViewItem-Klasse mit Properties für IsExpanded, IsSelected, ...

Nein.
Das ViewModel ist noch einmal eine weitere Klasse - z.B. PersonViewModel. Diese stellt sowohl IsExpanded (evtl. auch IsSelected) usw. aber auch alle Properties der Person Klasse bereit - mit dem Unterschied, dass PersonViewModel INotifyPropertyChanged implementiert.

Und das View ist dann praktisch das ItemTemplate dafür.

Ja, das kann man so sagen.

Das Model ist praktisch die TreeViewData-Klasse mit allen Daten (z.B. Name, Alter)
Was meinst du mit TreeViewData?
Unter einer Modelklasse verstehe ich z.B. eine Klasse Person.

Also eine reine Datenklasse ohne Logik und Verarbeitung?

Das ViewModel ist die TreeViewItem-Klasse mit Properties für IsExpanded, IsSelected, ...
Nein.
Das ViewModel ist noch einmal eine weitere Klasse - z.B. PersonViewModel. Diese stellt sowohl IsExpanded (evtl. auch IsSelected) usw. aber auch alle Properties der Person Klasse bereit - mit dem Unterschied, dass PersonViewModel INotifyPropertyChanged implementiert.

Und das ViewModel übernimmt dann die Verarbeitung, usw?

Hallo t-master,

Also eine reine Datenklasse ohne Logik und Verarbeitung?

zu MVVM kann ich nicht viel sagen, aber Person ist nicht gerade ein Beispiel für eine reine Datenklasse ohne Logik und Verarbeitung. Im Sinne der Objektorientierung gehört in eine Klasse immer beides: Zustand und Verhalten.

herbivore

ohje, irgendwie wird das immer komplizierter ^^
also ich hab das hier

-Paket
--File
--File

Paket und File besitzen eine Methode Update(double Fortschritt)
kommt die dann in das ViewModel oder in die jew. Klassen selbst?

edit: und sobald einem Paket ein neues File hinzugefügt wird, wird die Gesamtgröße des Pakets neu berechnet, wie siehts damit aus, Model oder ViewModel?

Also eine reine Datenklasse ohne Logik und Verarbeitung?
[...] aber Person ist nicht gerade ein Beispiel für eine reine Datenklasse ohne Logik und Verarbeitung. Im Sinne der Objektorientierung gehört in eine Klasse immer beides: Zustand und Verhalten.

Ja, da gebe ich herbivore vollkommen Recht.
Person wäre eine "normale" Geschäftsklasse mit allen dazugehörigen Properties, Methoden etc.
Im Prinzip bleibt es bei einer Mehrschichtenarchitektur, bei der die oberste Schicht (Präsentationsschicht) durch zwei Schichten ersetzt wird: ViewModel und "eigentliches" View.

Und das ViewModel übernimmt dann die Verarbeitung, usw?

Nein - nicht ganz.
Die Modelklassen stellen Methoden bereit, die dann vom ViewModel verwendet werden. Innerhalb dieser Methoden werden dann Daten verarbeitet, validiert usw.
Im Prinzip sind die Modelklassen an sich voll funktionsfähig.
Das ViewModel muss sie nur noch instanzieren (oder irgendwo herholen) und dann verwenden; das ViewModel an sich stellt keine Geschäftslogik bereit. Außerdem ist seine Aufgabe, die Daten so aufzubereiten und zusammenzustellen, dass sie einfach an ein Control gebunden werden können, wobei ein Control meist einer ViewModel Klasse entspricht.

Paket und File besitzen eine Methode Update(double Fortschritt)

Ganz klar in das Model.
Als einfach nachzuvollziehende Begründung: Es macht ja auch Sinn, ein Paket und eine Datei zu updaten ohne, dass diese irgendwo dargestellt werden.

und sobald einem Paket ein neues File hinzugefügt wird, wird die Gesamtgröße des Pakets neu berechnet, wie siehts damit aus, Model oder ViewModel?

Aus dem oben genannten Grund ebenfalls Model.
Hierbei ist wichtig, dass das ViewModel irgendwie über die Datenänderungen informiert werden muss.
Das kann entweder auch über INotifyPropertyChanged oder über andere Events wie "SizeChanged" oder indirekt über "PacketAdded".

Hallo,
Ich arbeite mich gerade in dias MVVM-Pattern ein.
Bisher sah meine Architektur wie folgt aus:

-DataLayer
der DAL holt die Daten aus der DB (Entity-Framework)

-BusinessLayer
hier werden die Daten aus dem DAL geholt und validiert um danach die GUI mit Daten zu füllen.
- GUI
Hier werden die Businessklassen benutzt, um die GUI zu füllen.

Meine Frage:

1. Normalerweise ist ja das Modell vom MVVM eine Klasse (z.B. Person mit all ihren Eigenschaften und Variablen ).
   Andererseits habe ich ja schon im DAL meine EF-Klassen, die per Entitymodel generiert werden.
   Brauche ich da jetzt noch die Klassen im Model oder ist das EF-Modell schon mein Model ?
   So richtig habe ich das noch nicht verstanden...

Wie könnte eine Mehrschichtige Architektur aussehen mit dem MVVM-Pattern ?

Wie könnte eine Mehrschichtige Architektur aussehen mit dem MVVM-Pattern ?

Wie gesagt: MVVM "ersetzt" lediglich die oberste Schicht, also den View der Mehrschichtenarchitektur:

--View---------------
| View              |
| ViewModel         |
| Model             |
---------------------

-- Business Layer --

-- DAL --

Brauche ich da jetzt noch die Klassen im Model oder ist das EF-Modell schon mein Model ?

Ja, brauchst du!
Bzw. solltest du, wenn dein Programm nicht sehr klein und einfach ist, haben.

Hallo,

ich möchte diesen Thread auch gerne noch mal aufleben lassen und kurz erläutern, wie ich es verstanden habe:

z.B. PersonenDaten:

Ich möchte das MVVm-Pattern benutzen, um Daten zu Personen aus einer Datenbank in einer WPF-GUI anzeigen.

Meine 1. Schicht, das View wäre dann meine Window1.xaml und Window1.xaml.cs, wobei in der .xaml.cs nur noch der Konstruktor mmit InitializeComponent stehen soll, damit die WPF-GUI, das View, komplett vom C#-Quellcode getrennt. Dies gibt dann die Möglichkeit, die GUI auszutauschen, z.B. in Silverlight.

Meine 2.Schicht, das ViewModel stellt C#-Klassen dar, PersonenDatenViewModel.cs, um
die Daten zu bearbeiten; Binding an die Controls in der GUI.

Die 3. Schicht, das Model (PersonenDatenModel.cs), ist in meinem Falle mein Entity-Framework, das Klasse bereitstellt, um die daten aus der datenbank zu holen, zu verwalten, Änderungen vorzunehmen etc.

Die 3 Schichten sollten dann am besten in 3 Projekten verwalten werden.
(Model.proj, ViewModel.proj und View.proj)

Ist dies schonmal richtig?

Vielen Dank im Voraus.

Mit freundlichen Grüßen
GIGGS