Model-View-Presenter (MVP)
Ein UI-Architekturmuster zur Trennung von Darstellung, Präsentationslogik und Datenmodell.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Presenter wird selbst zur komplizierten Geschäftslogik (God Object)
- Unsachgemäße Schnittstellendefinition erhöht Kopplung
- Fehlende Disziplin führt zu vermischten Verantwortlichkeiten
- Halte Views so passiv wie möglich; Logik im Presenter.
- Schreibe Presenter-Unit-Tests bevor UI-Integration.
- Vermeide Geschäftslogik im Presenter; delegiere an Domänenschicht.
I/O & Ressourcen
- UI-Spezifikationen und Benutzeranforderungen
- Existierendes Domänenmodell/Backend-APIs
- Testinfrastruktur (Unit-Tests, Mocks)
- Getrennte Presenter-, View- und Model-Komponenten
- Automatisierte Tests für Presenter
- Definierte Schnittstellen und Adapter
Beschreibung
Model-View-Presenter (MVP) ist ein UI-Architekturmuster zur Trennung von Darstellung, Logik und Daten. Der Presenter vermittelt zwischen Model und View, erhöht die Testbarkeit und trennt Verantwortlichkeiten klar. MVP eignet sich für komplexe Benutzeroberflächen mit wiederverwendbarer Präsentationslogik, modularer Struktur und verringerter Kopplung.
✔Vorteile
- Bessere Testbarkeit durch isolierte Presenter
- Klare Verantwortlichkeitsgrenzen zwischen UI und Domäne
- Wiederverwendbare Präsentationslogik über Plattformen
✖Limitationen
- Kann Boilerplate-Code durch viele Schnittstellen erzeugen
- Übermäßige Nutzung führt zu zu vielen Presenter-Klassen
- Nicht immer optimal für einfache, rein deklarative UIs
Trade-offs
Metriken
- Testabdeckung der Presenter
Prozentualer Anteil der Presenter-Funktionen, die durch automatisierte Tests abgedeckt sind.
- Anzahl der Presenter pro View
Misst die Modularität und Granularität der Präsentationsschicht.
- Zeit bis zur UI-Änderung (Durchlaufzeit)
Zeit, die benötigt wird, um eine UI-Änderung zu implementieren und zu testen.
Beispiele & Implementierungen
Desktop-Anwendung mit klaren Presenter-Tests
Eine Finanz-Desktop-Anwendung nutzt Presenter, um komplexe Eingabelogik zu kapseln und automatisiert zu testen.
Android-App mit Mosby-Framework
Eine Android-App implementiert MVP mittels der Mosby-Bibliothek zur Wiederverwendung von Presenter-Logik.
Refactoring einer WinForms-Oberfläche
Legacy WinForms-Code wurde schrittweise in Presenter ausgelagert, was die Testbarkeit verbesserte.
Implementierungsschritte
Identifiziere Views und extrahiere UI-Logik in Presenter.
Definiere klare Interfaces zwischen View und Presenter.
Implementiere Presenter mit Unit-Tests und verwende Mocks für Views/Model.
Integriere Presenter schrittweise in bestehende Views und refactore wiederholt.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Unrefaktorierte Presenter mit gemischter Logik
- Veraltete Adapter zwischen Presenter und Model
- Fehlende Testabdeckung in kritischen Presenter-Pfaden
Bekannte Engpässe
Beispiele für Missbrauch
- Verlagerung kompletter Domänenlogik in Presenter statt in Domänenschicht.
- Einführung von MVP für sehr einfache Formular-Views ohne Nutzen.
- Erzeugung vieler feingranularer Presenter mit redundanter Verantwortung.
Typische Fallen
- Presenter wird zum Bottleneck für Änderungen, wenn zu viel Verantwortung zentralisiert ist.
- Unklare Interface-Verträge führen zu wiederholtem Refactoring.
- Fehlende Tests erlauben schleichende Vermischung von Zuständigkeiten.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Plattform-API kann passive Views erzwingen
- • Einschränkungen von UI-Frameworks können Presenter-Design beeinflussen
- • Team-Erfahrung mit Muster und Testautomatisierung erforderlich