Wie wird das ViewModel in MVVM erstellt, um das Prinzip der einfachen Verantwortlichkeit nicht zu verletzen?

Question

Robert Martin sagt: "Es sollte nie mehr als einen Grund für eine Klasse zu ändern geben".

Betrachten wir die ViewModel-Klasse, die an eine Ansicht gebunden ist. Es ist möglich (oder sogar wahrscheinlich), dass das ViewModel aus Eigenschaften besteht, die nicht wirklich miteinander verwandt sind. Für kleine Ansichten kann das ViewModel ziemlich kohärent sein, aber während die Anwendung komplexer wird, wird das ViewModel Daten offen legen, die sich aus unterschiedlichen und nicht verwandten Gründen ändern können.

Sollten wir uns im Falle der ViewModel-Klasse Gedanken über das SRP-Prinzip machen oder nicht?

Answer 1

Die einzige Verantwortung von ViewModel besteht darin, die erforderlichen Informationen zur Verfügung zu stellen. Wenn die Ansicht unterschiedliche und nicht verwandte Eigenschaften benötigt, ist dies nicht wichtig, da das ViewModel nur einen Grund hat, sich zu ändern, und das ist die Ansicht, die andere Eigenschaften zeigt. Sie sollten sich also nicht zu viele Sorgen machen.

Das heißt, wenn das ViewModel wird riesig, vielleicht könnte man denken über die Aufteilung der Ansicht in mehrere Unteransichten zur Verbesserung der Wiederverwendbarkeit und halten Sie die Ansichten und die ViewModels verwaltbar.

Answer 2

Ja, aber das bedeutet nicht, dass schlechtes Design Sie nicht dazu zwingen könnte.

Answer 3

Ich stimme mit gcores überein.

Sobald Sie sehen, dass ViewModel auf mehr als zwei Bildschirmtexte wächst, ist es an der Zeit, ViewModel in mehrere untergeordnete Modelle aufzuteilen. Eine weitere Faustregel ist, dass ich nie mehr als zwei Verschachtelungsebenen innerhalb der XAML-Datei habe - wenn ein Teil der Ansicht zu komplex wird, ist es Zeit für das Refactoring der Ansicht - extrahiere das innere XAML in ein separates UserControl und erstelle es das entsprechende ViewModel, das bei der untergeordneten Ansicht der Standarddatenkontext sein wird.

Answer 4

Ich stimme zu, dass die Aufteilung Ihrer Bildschirme in mehrere Ansichten mit mehreren ViewModels notwendig ist, um Aufblähung und Komplexität zu reduzieren. Hier ist ein weiteres Muster, das ich verwendet habe, um zu helfen, SRP mit MVVM zu bleiben:

Hier ist ein Szenario. Mein ViewModel muss Daten abrufen und auf Filterbefehle von der Benutzeroberfläche reagieren. Ich erstelle das ViewModel, um in der Struktur zusammengesetzt zu sein. Das heißt, untergeordnete Klassen, die Zugriff auf private Mitglieder des ViewModel haben, führen lineare Aufgaben aus, z. B. die Filterung. Ich habe möglicherweise auch eine andere Kindklasse, die die erforderliche Logik für die Auswahl von Elementen basierend auf Kriterien ausführt. Du hast die Idee. Sobald das ViewModel bestimmte Funktionen ausführt, die sich über mehrere Methoden erstrecken, ist es möglicherweise ein guter Kandidat, um es an eine Kindklasse zu delegieren. Die untergeordneten Klassen bleiben Teil des Haupt-ViewModel. Dies ist nur eine Möglichkeit, die Größe des ViewModels zu reduzieren und das Testen dieser linearen Operationen einfacher zu machen.