Zum Hauptinhalt springen

MVP (Model–View–Presenter)

Einleitung​

MVP trennt UI-Logik konsequent von der Darstellung.

Die View ist passiv.
Der Presenter steuert Interaktionen, orchestriert Logik und bereitet Daten für die Anzeige auf.

Ziel:

Maximale Testbarkeit und minimale UI-Kopplung.

Einordnung

MVP ist ein UI-Architektur-Pattern auf Applikationsebene.

Es steht zwischen:

  • MVC (weniger strikt getrennt)
  • MVVM (mit deklarativer Bindung)

MVP eignet sich besonders für:

  • komplexe Interaktionslogik
  • testgetriebene UI-Entwicklung
  • imperative UI-Frameworks

Grundprinzip

Charakteristisch:

  • View enthält keine Geschäftslogik
  • Presenter kennt das View-Interface
  • Model kennt weder View noch Presenter

Zentrale Eigenschaften

1️⃣ Passive View​

Die View:

  • rendert Daten
  • leitet User-Events weiter
  • enthält keine Entscheidungslogik

Keine:

  • automatische Bindung
  • implizite Synchronisation

2️⃣ Presenter als Orchestrator​

Der Presenter:

  • verarbeitet UI-Events
  • ruft Use Cases / Services auf
  • validiert Eingaben
  • transformiert Domain-Daten für die View

Er ist:

Präsentationslogik in isolierbarer Form.

3️⃣ Testbarkeit​

Da Presenter gegen Interfaces arbeitet:

  • Unit-Tests ohne UI
  • Mockbare View
  • deterministische Logik

MVP ist stark TDD-kompatibel.

Vorteile

  • Hohe Testbarkeit
  • Klare Verantwortlichkeiten
  • Framework-Entkopplung
  • Gute Struktur bei komplexen Formular-Logiken

Risiken / typische Fallstricke

1️⃣ Presenter-Inflation​

Presenter kann:

  • zu groß werden
  • zu viele Verantwortlichkeiten übernehmen

2️⃣ Boilerplate​

Interfaces + Mapping-Code erhöhen Aufwand.

3️⃣ Nicht optimal für deklarative Frameworks​

In modernen reaktiven Frameworks mit:

  • Datenbindung
  • Signals
  • unidirektionalem Flow

kann MVP unnötig imperativ wirken.

Vergleich mit anderen Patterns

PatternViewLogik-OrtDatenfluss
MVCaktivControllerteilweise bidirektional
MVPpassivPresenterPresenter-gesteuert
MVVMdeklarativViewModelmeist bindungsgetrieben
MVIpassivReducerstrikt unidirektional

Wann sinnvoll?

  • Formularintensive Business-UIs
  • Hohe Testanforderungen
  • Imperative UI-Frameworks
  • Teams mit TDD-Fokus

Wann weniger sinnvoll?

  • Kleine, einfache UIs
  • Reaktive Frameworks mit starkem Binding
  • State-getriebene Architekturen (MVI geeigneter)

Strategische Perspektive

MVP ist:

  • stärker diszipliniert als MVC
  • weniger deklarativ als MVVM
  • weniger state-zentriert als MVI

Es eignet sich besonders dort, wo:

Präsentationslogik komplex ist, aber globaler State nicht dominiert.

Fazit

MVP ist ein robustes UI-Pattern für testbare Interaktionslogik.

Es bringt:

  • Klarheit
  • Isolation
  • Testbarkeit

kostet aber:

  • mehr Struktur
  • mehr Boilerplate

Für komplexe Business-UIs ist es oft ein stabiler Mittelweg.