Laden...

MVVM - Wie viele Klassen, wie viele ViewModel?

Erstellt von DonStivino vor 8 Jahren Letzter Beitrag vor 8 Jahren 2.594 Views
D
DonStivino Themenstarter:in
51 Beiträge seit 2014
vor 8 Jahren
MVVM - Wie viele Klassen, wie viele ViewModel?

Hallo zusammen,

ich versuche gerade eine größere Anwendung in WPF und nach dem MVVM-Muster umzusetzen. Nun habe ich eine grundsätzliche Frage:

Zur Vereinfachung einfach mal folgendes Szenario:

Ich habe eine Klasse Person und möchte eine variable Anzahl Personen in meinem View (Datagrid) darstellen. Für diesen View existiert ein ViewModel den der View bindet. Das heißt also ich habe im ersten Schritt 3 Klasse: Person, PersonView und sowas wie PersonViewViewModel. In PersonViewViewModel befindet sich dann eine ObservableCollection<Person> die das Datagrid bindet. Soweit so gut.

Nun gibt es unterhalb des Datagrid eine Detailsansicht zu der durch den Benutzer ausgewählten Person. Wenn der Benutzer hier etwas ändert, kann er anschließend einen Button "Save" klicken um die Änderungen abzuspeichern. Dazu bindet der Button das Command "Save" und übergibt die Person. Der View besteht also aus: DataGrid, Detailansicht, Save-Button.

Nun schon die Frage: Müsste ich nun nicht ein Property "HasUnsavedChanges" in Person anbieten? Das finde ich aber unschön, da dies doch ein Teil der View-Logik ist und überhaupt nichts mit meinem Model zu tun hat. Ich habe schon öfter solche Probleme bekommen, wie kann ich das Model vernünftig kapseln, sodass hier keine View-Details liegen müssen? Wie würdet ihr eine Funktionalität "Save all Changes" umsetzen?

Ein ViewModel pro Model-Klasse als Zwischenebene? Was ist aber wenn mehrere Model-Klassen auf einem View dargestellt werden müssen? Wie löst ihr das?

Gruß,

S

T
314 Beiträge seit 2013
vor 8 Jahren

Hi,

du solltest statt der Collection<Person> eine Collection<PersonDetailsViewModel> haben. Dies stellt dann die nötigen Properties bereit und ergänzt z.B. um HasUnsavedChanges.

In diesem PersonDetailsViewModel kann (nicht muss) dann auch das SaveCommand liegen für eine einzelne Person.

Ein SaveAllChangesCommand würde dann im PersonViewViewModel z.B. so aussehen.

 

foreach( var person in myPersonCollection.Where( p => p.HasUnsavedChanges)) {
       person.SaveChanges();
}

Das Ganze ist ja ein typsiches "Master-Detail" Szenario. Du kannst dir dazu auch mal http://www.codeproject.com/Articles/332615/WPF-Master-Details-MVVM-Application ansehen.

D
DonStivino Themenstarter:in
51 Beiträge seit 2014
vor 8 Jahren

Hallo,

du solltest statt der Collection<Person> eine Collection<PersonDetailsViewModel> haben. Dies stellt dann die nötigen Properties bereit und ergänzt z.B. um HasUnsavedChanges.

Mir kommt es so aufwändig vor für jede Model-Klasse ein ViewModel zu bauen. Hast du das schon öfter und für mal für eine größere Anwendung gemacht? Hat es sich bewährt?

Bin leider noch recht unerfahren (noch Student^^)...

Gruß

Steven

5.657 Beiträge seit 2006
vor 8 Jahren

Hi DonStivino,

meistens benötigt man ein ViewModel pro View. Dieses ViewModel repräsentiert dann eine oder mehrere (oder gar keine) Model-Klassen, je nachdem, welche Anforderungen an die View bestehen. Also alle Funktionalitäten, die in der View abgebildet werden sollen, müssen im jeweiligen ViewModel implementiert sein.

Christian

Weeks of programming can save you hours of planning

D
DonStivino Themenstarter:in
51 Beiträge seit 2014
vor 8 Jahren

Hallo

meistens benötigt man ein ViewModel pro View. Dieses ViewModel repräsentiert dann eine oder mehrere (oder gar keine) Model-Klassen, je nachdem, welche Anforderungen an die View bestehen.

Ein ViewModel ist ja praktisch Voraussetzung für MVVM-Pattern. Aber wenn ich alle Properties der Model-Klassen in einem ViewModel wieder aufgreife dann ist das meiner Meinung nach auch wieder sehr unsauber. Die Zusatzinformationen (wie HasChanges) sollen ja nicht aus dem Kontext gerissen werden. A propos Zusantzinformationen: Da dachte ich ja schon an "AttachedProperties", jedoch sind die wieder WPF-spezifisch und gehören nicht ins Model finde ich.

Die strenge Kapselung gestaltet sich schwierig finde ich. Vielleicht ist der Ansatz von t0ms3n am Ende recht gelungen. Mehrere ViewModel können ja immer noch in einem zusammen fließen. Die Frage ist nur, ob der Aufwand gerechtfertigt ist finde ich.

Gibt es noch mehr Ideen?

Vielen Dank schon mal 😃

5.657 Beiträge seit 2006
vor 8 Jahren

Ich verstehe nicht, was du mit "aus dem Kontext gerissen" meinst. So wie ich es verstehe, wird dein HasChanges-Property nur für die View benötigt, und muß daher im ViewModel, aber nicht im Model vorhanden sein.

Über das Für und Wider des Einsatzes von MVVM kann man streiten, und es ist auch schon oft darüber gestritten worden. Aber da verweise ich auf die Forensuche, wir müssen die Diskussion ja nicht immer wieder von vorne beginnen. Kurz gesagt: Wenn du die Vorteile von MVVM nutzen willst, mußt du mit den Nachteilen leben. Für die meisten von uns überwiegen die Vorteile. Und es gibt Bibliotheken, die dir u.a. das manuelle Erstellen der ViewModels z.T. abnehmen können.

Attached Properties und Dependency Properties im allgemeinen haben damit nichts zu tun, und spielen nur in der View (Steuerelemente etc.) eine Rolle.

Christian

Weeks of programming can save you hours of planning

D
DonStivino Themenstarter:in
51 Beiträge seit 2014
vor 8 Jahren

Die Properties zum View hängen doch u.U. stark mit denen des Models zusammen. Ob eine Person ungesicherte Änderungen hat hängt doch genau mit dieser Personen-Instanz (dem Objekt) zusammen. Da sehe ich eine klare Zusammengehörigkeit. Dennoch ist das keine Sache des Models, da dies doch nichts ist was einer Person selbst zugeordnet werden kann. Bei einem einzigen Model welches im View dargestellt wird mag der Ansatz mit einem ViewModel dann ja ausreichen, wenn aber mehrere Model-Klassen zusammen kommen erscheint mir der Ansatz von t0ms3n im Sinne der Kapselung tragfähiger, schließlich kann hier die Person inklusive ihrer Zusatzinformationen wieder gekapselt werden und genau so auch andere Model-Objekte.

Ich habe keineswegs über das Für und Wider von MVVM diskutieren wollen. Ich sehe die Vorzüge ein, ich suche nur nach einem tragfähigen Konzept das auf MVVM basiert und meine Anforderungen berücksichtigt. Sorry falls das falsch rüber gekommen ist, ich wollte keine Kritik an der Technologie üben.

Steven

5.657 Beiträge seit 2006
vor 8 Jahren

Bei einem einzigen Model welches im View dargestellt wird mag der Ansatz mit einem ViewModel dann ja ausreichen, wenn aber mehrere Model-Klassen zusammen kommen erscheint mir der Ansatz von t0ms3n im Sinne der Kapselung tragfähiger, schließlich kann hier die Person inklusive ihrer Zusatzinformationen wieder gekapselt werden und genau so auch andere Model-Objekte.

Was ist denn deine Frage in dem Zusammenhang? Wo liegt das Problem? Wie können wir dir helfen?

Weeks of programming can save you hours of planning

D
DonStivino Themenstarter:in
51 Beiträge seit 2014
vor 8 Jahren

Mir ging es darum wie man das Model so weit kapseln kann, dass es tatsächlich unabhängig vom View ist. Damit meine ich auch bezüglich Eigenschaften, die lediglich zur Darstellung benötigt werden. Praktisch Zusatzinformationen. Da gefällt mir der Ansatz von t0ms3n ganz gut denke ich...

Was sind das eigentlich für Bibliotheken die du angesprochen hast? Bezüglich der Unterstützung beim Erstellen von ViewModeln?

Gruß

Steven