Zum Hauptinhalt springen

MVVM (Model–View–ViewModel)

Einleitung​

MVVM stellt Datenbindung in den Mittelpunkt der UI-Architektur.

Zwischen Model und View liegt ein ViewModel, das:

  • UI-Zustand kapselt
  • Commands bereitstellt
  • Daten für die Darstellung transformiert

Ziel:

Entkopplung der View bei gleichzeitiger hoher Produktivität durch Binding.

Einordnung

MVVM ist ein UI-Architektur-Pattern auf Applikationsebene.

Es ist besonders geeignet für:

  • Frameworks mit deklarativer Datenbindung
  • zustandsgetriebene UIs
  • komponentenbasierte Architekturen

MVVM ist kein Systemstil und kein State-Management-Framework.

Grundprinzip

Charakteristisch:

  • View kennt ViewModel
  • ViewModel kennt View nicht
  • Model kennt weder View noch ViewModel

Zentrale Konzepte

1️⃣ ViewModel als Adapter​

Das ViewModel:

  • transformiert Domain-Daten in UI-geeignete Form
  • kapselt Präsentationszustand
  • stellt Commands bereit

Es ist:

Präsentationslogik, nicht Domänenlogik.

2️⃣ Datenbindung​

Binding kann sein:

  • unidirektional (State → View)
  • bidirektional (View ↔ ViewModel)

Bidirektionales Binding erhöht Produktivität, aber reduziert Transparenz des Datenflusses.

3️⃣ Trennung von Domäne und UI​

Model:

  • enthält Geschäftslogik

ViewModel:

  • enthält Präsentationslogik

Die Grenze muss sauber gehalten werden.

Vorteile

  • Hohe Produktivität durch deklarative Bindung
  • Gute Testbarkeit des ViewModels
  • Klare Trennung von View und Logik
  • Gut skalierbar in komponentenbasierten Systemen

Risiken / typische Fallstricke

1️⃣ Fett-ViewModels​

Wenn Business-Logik ins ViewModel wandert:

→ Architektur erodiert.

2️⃣ Komplexe Bindings​

Tief verschachtelte Bindings führen zu:

  • schwer nachvollziehbarem Datenfluss
  • Debugging-Problemen

3️⃣ Framework-Abhängigkeit​

MVVM ist oft stark an:

  • Binding-Mechanismen
  • Framework-Lifecycle

gekoppelt.

4️⃣ Impliziter State​

Bidirektionale Bindung kann:

  • implizite Zustandsänderungen erzeugen
  • Debugging erschweren

MVVM im Vergleich

PatternDatenflussState-KontrolleTestbarkeit
MVCteilweise bidirektionalmittelmittel
MVPPresenter-gesteuerthochhoch
MVVMbinding-getriebenmittel–hochhoch
MVIstrikt unidirektionalsehr hochsehr hoch

Wann sinnvoll?

  • Framework mit starkem Binding (z. B. Angular, WPF)
  • Formularintensive Business-UIs
  • Wiederverwendbare UI-Komponenten
  • Gute Balance aus Produktivität und Struktur

Wann weniger sinnvoll?

  • Sehr einfache UIs
  • Strikt unidirektionaler Architekturansatz gewünscht
  • Hohe Anforderungen an deterministischen State (→ MVI)

Strategische Perspektive

MVVM ist:

  • produktiver als MVP
  • weniger strikt als MVI
  • moderner als klassisches MVC

Es eignet sich gut für:

mittelkomplexe bis komplexe UIs mit klarer Trennung von Präsentation und Domäne.

Für sehr große Frontend-Systeme kann jedoch:

  • unidirektionaler State (MVI/Flux)
  • klarere State-Governance

robuster sein.

Fazit

MVVM bietet:

  • saubere Trennung
  • gute Testbarkeit
  • hohe Produktivität

Es erfordert jedoch Disziplin, damit:

  • ViewModel nicht zur Logik-Deponie wird
  • Binding nicht zum Debugging-Albtraum wird.