Katalog
concept#Architektur#Software-Engineering#Plattform

Model-View-ViewModel (MVVM)

Architekturpattern zur Trennung von Darstellung, Logik und Zustandsverwaltung in UI-Anwendungen. Fördert Testbarkeit und Wiederverwendbarkeit von Komponenten.

MVVM ist ein strukturelles Architekturpattern, das Model, View und ViewModel trennt, um Zustandsverwaltung, Präsentationslogik und UI-Darstellung zu entkoppeln.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Dependency-Injection-ContainerAsync-Datenquellen / REST-APIsPersistenz- oder Repository-Schicht

Prinzipien & Ziele

Trennung von Zuständen, Darstellung und LogikViewModels sind zustands- und präsentationslogikzentriert, nicht UI-ElementeDatenbindung und Commands statt direkter UI-Manipulation
Umsetzung
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Übermäßige Komplexität durch falsch strukturierte ViewModels
  • Verdeckung von Performance-Problemen durch zu viele Bindings
  • Falsche Verwendung kann Testing-Überzeugung schwächen (z. B. logik in Views)
  • Halte ViewModels schlank: keine direkten UI-Kontexte referenzieren
  • Nutze Commands statt Event-Handler in Views
  • Führe klare Namenskonventionen für Bindings und Properties ein

I/O & Ressourcen

  • Domänenmodell
  • UI-Designspezifikation
  • Zugriff auf persistente Datenquellen
  • ViewModels mit klarer Präsentationslogik
  • Bindings und Commands in Views
  • Automatisierte Tests für Präsentationsschicht

Beschreibung

MVVM ist ein strukturelles Architekturpattern, das Model, View und ViewModel trennt, um Zustandsverwaltung, Präsentationslogik und UI-Darstellung zu entkoppeln. Es erleichtert Unit-Testing und modularen Aufbau von Benutzerschnittstellen. Gängig in Desktop- und mobilen .NET-Anwendungen sowie plattformübergreifenden UI-Frameworks.

  • Erhöhte Testbarkeit durch isolierte ViewModel-Logik
  • Bessere Modularität und Wiederverwendbarkeit von Komponenten
  • Erleichtert parallele Entwicklung von UI und Logik

  • Erhöhter Boilerplate-Aufwand für Bindings und Property-Implementierung
  • Nicht jede UI-Interaktion lässt sich sauber abstrahieren
  • Eignet sich schlechter für sehr einfache UIs ohne Zustandslogik

  • Abdeckung der ViewModel-Unit-Tests

    Prozentsatz der Logikmethoden und Zustände, die durch Unit-Tests abgedeckt sind.

  • Anzahl wiederverwendeter ViewModels

    Menge von ViewModels, die across multiple views or platforms reused werden.

  • Durchschnittliche Bindungs-Latenz

    Messung der Zeit, die Bindings benötigen, um UI-Updates zu propagieren.

Referenzprojekt: WPF To-Do App

Kleine Desktop-App, die MVVM für Bindings, Commands und Persistenz nutzt.

Plattformübergreifende Notizen-App (.NET MAUI)

Beispiel für gemeinsames ViewModel und separaten Views für iOS/Android.

Komplexes Formular-Modul

Modul mit Validierung, Undo/Redo und asynchroner Datensynchronisation via ViewModel.

1

Identifiziere Views, extrahiere Zustandslogik in ViewModels und definiere Bindings.

2

Implementiere Commands und Notification-Mechanismen (INotifyPropertyChanged).

3

Sorge für Dependency Injection und schreibe Unit-Tests für ViewModels.

⚠️ Technische Schulden & Engpässe

  • Unvollständige Trennung von UI- und Logik-Code im Legacy-ViewModel
  • Fehlende Tests für ViewModel-Grenzfälle
  • Ad-hoc-Bindings ohne Namenskonventionen erschweren Refactoring
Binding-PerformanceViewModel-GrößeLifecycle-Synchronisation
  • Verwendung von MVVM in einer App mit einer einzigen statischen View führt zu unnötigem Overhead.
  • ViewModel als Repository- oder Persistenzschicht missbrauchen.
  • Business-Logik in View-Events verstecken statt in ViewModel kapseln.
  • Unbedachte Bindings verursachen Speicherlecks oder Performanceprobleme
  • Zu feingranulare ViewModels führen zu Overhead und Komplexität
  • Ignore platform lifecycle differences when reusing ViewModels
Kenntnis von Datenbindung und UI-Frameworks (z. B. WPF, MAUI)Erfahrung mit Unit-Testing und MockingVerständnis von Asynchronität und State-Management
Testbarkeit der PräsentationslogikWiederverwendbarkeit über PlattformenKlare Verantwortungsgrenzen im UI-Stapel
  • Benötigt UI-Framework mit Datenbindung oder vergleichbarer API
  • Erfordert Disziplin bei Trennung von UI- und Logik-Code
  • Eingeschränkte Effektivität bei sehr einfachen UIs