🇩🇪 Model-View-ViewModel Architektur

MVVM.md

Model-View-ViewModel Architektur

Das "Model" im MVVM-Schema enthält die Daten und die Logik, die direkt mit diesen Daten verbunden ist.
Das "ViewModel" transformiert diese Daten in eine Form, die für die Darstellung auf der Benutzeroberfläche geeignet ist und verwaltet die Interaktion zwischen der UI und den Modellen. Es verbindet die UI-Anforderungen (wie sie im View geäußert werden) mit den Datenoperationen, die im Model definiert sind.

1. Model: Das erste M in MVVM repräsentiert das "Model". In dieser Rolle fungiert es als die Repräsentation der Datenstruktur, zusammen mit der Geschäftslogik, die Daten manipuliert. Das Modell ist verantwortlich für:

   • Den Zugriff auf die Datenquelle (z.B. Datenbank, Webdienste).
   • Die Implementierung der Geschäftsregeln oder Logik, die spezifisch für die Daten oder die Domäne sind.
   • Die Aufrechterhaltung des Zustands der Daten (aber nicht des Zustands der UI).
   • Benachrichtigungen über Änderungen in seinen Daten durch Implementierungen wie INotifyPropertyChanged, wenn dies für die Anwendung notwendig ist.

   Modelle sind in der Regel unabhängig von spezifischen UI-Technologien und können in verschiedenen Anwendungen wiederverwendet werden.

2. ViewModel: Das zweite M in MVVM steht für "ViewModel". Das ViewModel agiert als Mittler zwischen dem View und dem Model. Es ist verantwortlich für:

   • Die Transformation von Modellinformationen in Werte, die leicht im View dargestellt werden können (zum Beispiel das Konvertieren von Datumsformaten, die Zusammenstellung von spezifischen Ansichten aus mehreren Datenquellen usw.).
   • Die Reaktion auf Befehle oder Aktionen des Benutzers (z.B. Button-Klicks, Auswahländerungen), oft durch Command-Patterns realisiert.
   • Die Verwaltung des Zustands der Präsentation (UI-spezifische Zustände wie z.B. die Sichtbarkeit von Elementen oder die Auswahl in einem Drop-Down-Menü).
   • Die Weiterleitung von Änderungen an das Modell oder Anfragen von Daten vom Modell, oft ohne spezifisches Wissen über die UI selbst.

3. View Die View (Z.B. die MainWindow-Klasse) sollte sich primär auf UI-Aspekte konzentrieren, wie z. B. Fenstereigenschaften, die Darstellung und das Event-Handling. Der Code-Behind in der MainWindow sollte möglichst minimal sein und vorwiegend für direkte UI-Operationen verwendet werden. Um Geschäftslogik und die Zustandsverwaltung sollte sich das ViewModel kümmern.

Details

Die View in der MVVM-Architektur spricht über das ViewModel mit dem Model (Schichtentrennung):

1. Model: Dies ist die niedrigste Ebene und beinhaltet die Geschäftslogik und die Datenzugriffslogik. Das Model ist verantwortlich für die Abfrage, Speicherung und Manipulation der Daten, oft durch Kommunikation mit einer Datenbank oder anderen Diensten.

2. ViewModel: Das ViewModel fungiert als Bindeglied zwischen der View und dem Model. Es nimmt Daten vom Model auf, transformiert sie in Formate, die leichter von der View genutzt werden können (zum Beispiel durch Aufbereitung von Datumsformaten oder das Kombinieren von Daten aus mehreren Quellen), und stellt diese Daten der View zur Verfügung. Es nimmt auch Befehle von der View entgegen (zum Beispiel durch Benutzeraktionen wie Klicks) und führt entsprechende Aktionen im Model aus.

3. View: Die View ist das, was der Benutzer sieht. Es ist die Benutzeroberfläche, die die vom ViewModel bereitgestellten Daten darstellt und Benutzerinteraktionen einfängt und an das ViewModel weiterleitet.

Das ViewModel dient als zentrale Vermittlungsinstanz, durch die alle Kommunikation zwischen der Benutzeroberfläche (View) und den Geschäftsdaten (Model) fließt. Es ist hilfreich zu denken, dass das ViewModel sowohl zum Model als auch zur View "spricht", um eine klare Trennung der Verantwortlichkeiten zu gewährleisten:

• Die View kennt nur das ViewModel und reagiert auf Benutzereingaben oder stellt Daten dar, ohne die Geschäftslogik oder Datenquelle zu kennen.
• Das ViewModel kennt das Model und kann Daten anfordern oder aktualisieren, weiß aber nichts über die spezifische Implementierung der UI.
• Das Model ist völlig unabhängig von der Darstellung und fokussiert sich auf die Geschäftslogik und Daten.

Diese Trennung ermöglicht es, jede Schicht unabhängig von den anderen zu entwickeln und zu testen, was insbesondere in großen und komplexen Anwendungen von Vorteil ist.

Aufteilung der Geschäftslogik

ViewModel kann durchaus Geschäftslogik enthalten sein, insbesondere Logik, die spezifisch für die Darstellung oder die Handhabung von Benutzerinteraktionen ist. Die Aufteilung der Geschäftslogik zwischen dem Model und dem ViewModel hängt von deren spezifischer Funktion innerhalb der Anwendung ab. Hier sind einige Leitlinien, wie du entscheiden kannst, wo Geschäftslogik platziert werden sollte:

Geschäftslogik im Model

• Datenintegrität und Validierung: Logik, die sicherstellt, dass Daten konsistent und gültig sind, sollte im Model liegen. Dies umfasst Validierungen, die unabhängig von der Benutzeroberfläche gelten, wie z.B. die Überprüfung, ob ein Benutzername eindeutig ist oder ob Transaktionsdaten vollständig sind.
• Datenmanipulation: Operationen, die Daten erstellen, lesen, aktualisieren oder löschen (CRUD-Operationen), gehören ins Model. Dies stellt sicher, dass das Model als einzige Quelle der Wahrheit für Daten dient.
• Wiederverwendbare Geschäftsprozesse: Wenn ein Geschäftsprozess in verschiedenen Teilen der Anwendung wiederverwendet wird, sollte er im Model implementiert werden, um Duplikation zu vermeiden und die Wartung zu erleichtern.

Geschäftslogik im ViewModel

• Datenpräsentation: Logik, die bestimmt, wie Daten formatiert oder kombiniert werden, um sie für die Benutzer ansprechend und verständlich zu machen. Beispiele sind das Formatieren von Datumsangaben, Währungen oder die Kombination von Daten aus mehreren Modellen für die Darstellung.
• Zustandsmanagement der UI: Logik, die den Zustand der Benutzeroberfläche verwaltet, wie z.B. welche Elemente sichtbar oder aktiviert sind, basierend auf den Rechten des Benutzers oder anderen Bedingungen.
• Reaktion auf Benutzeraktionen: Die Logik, die auf Benutzereingaben wie Klicks oder Eingaben reagiert, gehört typischerweise ins ViewModel. Dies umfasst die Entscheidung, welche Aktionen ausgeführt werden, wenn Benutzer bestimmte Steuerelemente verwenden.

Kriterien für die Aufteilung

• Trennung von Interessen: Geschäftslogik, die eng mit der Benutzeroberfläche verbunden ist, gehört ins ViewModel. Logik, die grundlegende Geschäftsregeln und Datenoperationen definiert, gehört ins Model.
• Testbarkeit: Model-Logik sollte so gestaltet sein, dass sie unabhängig von der UI getestet werden kann. ViewModel-Logik kann auf Interaktion und Darstellung fokussieren und oft mit Mocking-Techniken getestet werden.
• Wiederverwendbarkeit: Code, der in unterschiedlichen Kontexten oder Projekten wiederverwendet werden könnte, sollte im Model platziert werden, um die Wiederverwendung zu maximieren.

Durch die Beachtung dieser Kriterien kannst du eine saubere Architektur fördern, die leicht zu warten und zu skalieren ist.

( With ♥ by C# XAML Csharp GPT and me. )