MVP

MVP (Model-View-Presenter) ist ein Architekturmuster, das die Benutzeroberfläche in drei Komponenten trennt: Model (Daten), View (passive Darstellung) und Presenter (Steuerungslogik).

MVP (Model-View-Presenter) ist ein Architekturmuster zur Strukturierung von Benutzeroberflächen in der Softwareentwicklung. Es trennt eine Anwendung in drei Komponenten: das Model (Datenmodell und Geschäftslogik), die View (passive Benutzeroberfläche) und den Presenter (Vermittler zwischen Model und View). Der entscheidende Unterschied zum verwandten MVC-Pattern liegt darin, dass die View in MVP vollständig passiv ist und keine direkte Verbindung zum Model hat.

Geschichte und Entwicklung

Das MVP-Pattern entstand in den frühen 1990er Jahren bei Taligent, einem Joint Venture von Apple, IBM und Hewlett-Packard. MVP diente als grundlegendes Programmiermodell für die Anwendungsentwicklung in Taligents C++-basierter CommonPoint-Umgebung.

Mike Potel, Vice President und Chief Technology Officer von Taligent, formalisierte und veröffentlichte das MVP-Pattern 1996 in einem Whitepaper mit dem Titel "MVP: Model-View-Presenter. The Taligent Programming Model for C++ and Java". Potel beschrieb MVP als einheitliches konzeptuelles Programmiermodell, das sich an verschiedene Multi-Tier-Anwendungen und Client/Server-Architekturen anpassen lässt.

Wichtige Meilensteine

Nach dem Ende von Taligent 1997 entwickelte sich das MVP-Pattern weiter. Andy Bower und Blair McGlashan von Dolphin Smalltalk adaptierten das Muster für ihr Smalltalk-UI-Framework und trugen so zur Verbreitung bei.

• 1990er Jahre: Entstehung bei Taligent als Weiterentwicklung von MVC
• 1996: Formale Veröffentlichung durch Mike Potel
• 1997: Anpassung für Dolphin Smalltalk durch Bower und McGlashan
• 2006: Microsoft integriert MVP in die .NET-Framework-Dokumentation
• 2010er Jahre: Verbreitung in der Android-Entwicklung als Alternative zu MVC

Die drei Komponenten

MVP basiert wie MVC auf dem Prinzip der Separation of Concerns (Trennung der Zuständigkeiten). Der entscheidende Unterschied liegt in der Rolle des Presenters und der Passivität der View.

Model (Datenmodell)

Das Model enthält die Geschäftslogik und verwaltet den Zustand der Anwendung. Es ist identisch zum Model in MVC und hat keine Kenntnis von View oder Presenter.

• Verwaltet Daten und Anwendungszustand
• Enthält die Geschäftslogik und Validierungsregeln
• Kommuniziert mit Datenquellen (Datenbank, APIs)
• Ist vollständig unabhängig von der Präsentationsschicht

View (Passive Präsentationsschicht)

Die View in MVP ist vollständig passiv. Sie zeigt nur das an, was der Presenter ihr vorgibt, und leitet alle Benutzereingaben direkt an den Presenter weiter. Die View enthält keinerlei Logik zur Datenverarbeitung oder -formatierung.

• Stellt die Benutzeroberfläche bereit
• Hat keine direkte Verbindung zum Model
• Delegiert alle Benutzereingaben an den Presenter
• Implementiert ein Interface, das der Presenter verwendet
• Enthält keine Geschäfts- oder Präsentationslogik

Presenter (Vermittler)

Der Presenter ist das Herzstück von MVP. Er fungiert als Vermittler zwischen Model und View und übernimmt die gesamte Präsentationslogik. Der Presenter reagiert auf Benutzereingaben von der View, aktualisiert das Model und steuert anschließend die Darstellung in der View.

• Empfängt Benutzereingaben von der View
• Enthält die Präsentationslogik (Formatierung, Validierung)
• Aktualisiert das Model bei Benutzeraktionen
• Ruft Daten vom Model ab und bereitet sie für die View auf
• Steuert aktiv die View über deren Interface

Wie MVP funktioniert

Der Datenfluss in MVP unterscheidet sich deutlich von MVC. Die View hat keine direkte Verbindung zum Model - alle Kommunikation läuft über den Presenter:

1. Der Benutzer interagiert mit der View (z.B. klickt einen Button)
2. Die View delegiert die Aktion an den Presenter
3. Der Presenter verarbeitet die Eingabe und aktualisiert das Model
4. Der Presenter fragt neue Daten vom Model ab
5. Der Presenter formatiert die Daten und aktualisiert die View

Ein praktisches Beispiel: In einer Benutzerregistrierung gibt der Nutzer seine Daten ein und klickt auf "Registrieren". Die View informiert den Presenter über den Klick. Der Presenter validiert die Eingaben, ruft das Model auf, um den Benutzer zu speichern, und weist anschließend die View an, eine Erfolgsmeldung anzuzeigen oder Fehlermeldungen darzustellen.

MVP-Varianten

Martin Fowler beschrieb in seiner Analyse von UI-Architekturmustern zwei wichtige Varianten von MVP, die sich in der Striktheit der View-Passivität unterscheiden:

Passive View

Die Passive View-Variante ist die strikteste Form von MVP. Die View hat keinerlei Kenntnis vom Model und enthält keine Logik. Jede noch so kleine Aktualisierung der Oberfläche wird vom Presenter gesteuert.

• Maximale Testbarkeit: Der Presenter lässt sich vollständig ohne echte View testen
• Klare Verantwortlichkeiten: Alle Logik befindet sich im Presenter
• Mehr Boilerplate-Code: Jede View-Änderung erfordert expliziten Presenter-Aufruf

Supervising Controller

Die Supervising Controller-Variante erlaubt der View, sich über Data Binding direkt an einfache Daten des Models zu binden. Der Presenter greift nur bei komplexerer Logik ein.

• Weniger Code: Einfache Datenbindung reduziert Boilerplate
• Flexibler: Gut geeignet für moderne Data-Binding-Frameworks
• Kompromiss: Weniger strikte Trennung als Passive View

Codebeispiel in Java

Das folgende Beispiel zeigt eine typische MVP-Implementierung für eine einfache Login-Funktionalität. Beachte, wie die View nur über ein Interface angesprochen wird:

// View Interface - definiert, was der Presenter mit der View machen kann
public interface LoginView {
    String getUsername();
    String getPassword();
    void showLoginSuccess();
    void showLoginError(String message);
    void showLoading();
    void hideLoading();
}

// Model - enthält die Geschäftslogik
public class LoginModel {
    public boolean authenticate(String username, String password) {
        // Hier würde die echte Authentifizierung stattfinden
        return username.equals("admin") && password.equals("1234");
    }
}

// Presenter - vermittelt zwischen View und Model
public class LoginPresenter {
    private final LoginView view;
    private final LoginModel model;

    public LoginPresenter(LoginView view, LoginModel model) {
        this.view = view;
        this.model = model;
    }

    public void onLoginClicked() {
        String username = view.getUsername();
        String password = view.getPassword();

        // Validierung im Presenter
        if (username.isEmpty() || password.isEmpty()) {
            view.showLoginError("Bitte alle Felder ausfüllen");
            return;
        }

        view.showLoading();

        // Model aufrufen
        boolean success = model.authenticate(username, password);

        view.hideLoading();

        if (success) {
            view.showLoginSuccess();
        } else {
            view.showLoginError("Ungültige Anmeldedaten");
        }
    }
}

Vergleich: MVP vs. MVC

MVP und MVC verfolgen ähnliche Ziele, unterscheiden sich aber in wichtigen Aspekten. Die folgende Tabelle fasst die wesentlichen Unterschiede zusammen:

Der Hauptvorteil von MVP liegt in der verbesserten Testbarkeit. Da die View nur über ein Interface angesprochen wird, kann der Presenter mit einem Mock-Objekt anstelle der echten View getestet werden. Dies macht Unit-Tests deutlich einfacher und zuverlässiger.

Einsatzgebiete

MVP eignet sich besonders für Anwendungen, bei denen eine saubere Trennung zwischen UI und Logik wichtig ist:

Mobile Entwicklung

MVP war lange Zeit das bevorzugte Architekturmuster in der Android-Entwicklung, bevor MVVM mit Jetpack an Bedeutung gewann. Die klare Trennung hilft, den komplexen Activity-Lifecycle zu managen.

• Android-Apps mit komplexer Geschäftslogik
• iOS-Anwendungen (häufig als VIPER-Variante)
• Cross-Platform-Entwicklung

Desktop-Anwendungen

In der Desktop-Entwicklung ermöglicht MVP eine saubere Trennung der UI-Logik. Dies ist besonders wertvoll bei Windows Forms oder WPF-Anwendungen, wo die View-Komponenten oft komplex sind.

• Windows Forms (C#/.NET)
• WPF-Anwendungen
• Swing/JavaFX-Anwendungen
• Electron-Apps

Vor- und Nachteile

Vorteile

• Exzellente Testbarkeit: Presenter kann isoliert mit Mock-Views getestet werden
• Klare Trennung: View enthält keine Logik, Presenter keine UI-Details
• Lose Kopplung: View und Model sind vollständig entkoppelt
• Wiederverwendbarkeit: Presenter-Logik kann für verschiedene Views genutzt werden
• Wartbarkeit: Änderungen an der UI erfordern keine Änderungen an der Logik

Nachteile

• Mehr Boilerplate: Jede View benötigt ein Interface und einen Presenter
• Komplexität: Für kleine Projekte kann MVP überdimensioniert sein
• 1:1-Beziehung: Jede View braucht einen eigenen Presenter
• View-Interface-Pflege: Bei UI-Änderungen muss das Interface angepasst werden

MVP lohnt sich besonders bei mittleren bis großen Projekten, bei denen Testbarkeit und Wartbarkeit wichtiger sind als schnelle initiale Entwicklung. Für Prototypen oder sehr einfache Anwendungen ist der Overhead oft nicht gerechtfertigt.

MVP in der Praxis

MVP findet in vielen professionellen Softwareprojekten Anwendung, besonders dort, wo qualitativ hochwertige, gut getestete Software gefragt ist. In Agenturen und Softwarehäusern, die Mobile-Apps entwickeln, war MVP lange Zeit der Standard für Android-Projekte.

Wer als Fachinformatiker für Anwendungsentwicklung arbeitet, sollte neben MVC auch MVP kennen. Das Verständnis verschiedener Architekturmuster hilft dir, für jedes Projekt die passende Struktur zu wählen. In der Praxis begegnen dir oft Mischformen oder Weiterentwicklungen wie MVVM (Model-View-ViewModel), das insbesondere in modernen Frontend-Frameworks Verwendung findet.

Quellen und weiterführende Links

• Wikipedia: Model-View-Presenter
• Martin Fowler: GUI Architectures
• Martin Fowler: Passive View
• Android Architecture Guide
• GeeksforGeeks: MVC vs MVP