Was sind die Unterschiede zwischen den Architekturmustern MVC und MVP?

MVC (Model-View-Controller) und MVP (Model-View-Presenter) sind zwei beliebte Architektur-Pattern, die dazu dienen, eine Anwendung in Komponenten zu unterteilen, um Wartbarkeit und Testbarkeit zu verbessern. Die wichtigsten Unterschiede liegen in der Verantwortlichkeitsverteilung und der Interaktion zwischen den Komponenten.

MVC (Model-View-Controller):

• Model: Enthält die Daten der Anwendung und die Geschäftslogik. Es ist nicht über die View oder den Controller informiert.
• View: Zeigt die Daten des Models an und verarbeitet Benutzeraktionen (z.B. Button-Klicks). Die View ist direkt mit dem Model verbunden (zieht Daten daraus).
• Controller: Agiert als Vermittler zwischen Model und View. Empfängt Benutzeraktionen von der View, aktualisiert das Model und wählt die View zur Anzeige aus.

Im MVC sind View und Controller eng verbunden. Die View kann direkt auf das Model zugreifen, was die Testbarkeit der View erschweren kann. Der Controller aktualisiert das Model, das wiederum die View über Änderungen informiert (oft über KVO oder NotificationCenter).

MVP (Model-View-Presenter):

• Model: Ähnlich wie im MVC, enthält Daten und Geschäftslogik.
• View: Zeigt die Daten an und leitet alle Benutzeraktionen an den Presenter weiter. Die View ist eine passive Entität, die keine Geschäftslogik enthält und nicht direkt mit dem Model interagiert.
• Presenter: Agiert als Controller, aber mit anderen Verantwortlichkeiten. Empfängt Benutzeraktionen von der View, interagiert mit dem Model zur Aktualisierung der Daten und aktualisiert die View durch Aufruf ihrer Methoden. Der Presenter kennt die View und das Model.

Im MVP ist die View vollständig vom Model getrennt. Der Presenter agiert als Vermittler, der die Logik zwischen View und Model verwaltet. Der Presenter aktualisiert die View, indem er Daten "push"-artig an sie liefert. Das macht die View "dümmer" (dumb) und erleichtert das isolierte Testen des Presenters.

Vergleichstabelle:

Merkmal	MVC	MVP
Verbindung View mit Model	View kann direkt auf das Model zugreifen	View kennt das Model nicht
Hauptverantwortung	Controller	Presenter
Aktualisierung der View	Model benachrichtigt View (Pull)	Presenter aktualisiert View (Push)
"Intelligenz" der View	Kann Präsentationslogik enthalten	Passiv, enthält minimal Logik
Testbarkeit	Tests der View können schwieriger sein	Tests des Presenters sind einfacher
Abhängigkeiten	Controller hängt von View und Model ab	Presenter hängt von View und Model ab

Beispiel für die Interaktion (vereinfacht):

MVC:

1. Benutzer klickt auf Button in der View.
2. View benachrichtigt den Controller.
3. Controller verarbeitet die Aktion, aktualisiert ggf. das Model.
4. Model benachrichtigt die View über Datenänderungen.
5. View aktualisiert ihre Oberfläche, indem sie Daten aus dem Model abruft.

MVP:

1. Benutzer klickt auf Button in der View.
2. View leitet die Aktion an den Presenter weiter (z.B. ruft Methode im View-Protokoll auf).
3. Presenter verarbeitet die Aktion, interagiert mit dem Model.
4. Presenter erhält die aktualisierten Daten vom Model.
5. Presenter aktualisiert die View, indem er ihre Methoden aufruft (z.B. view.display(updatedData)). Die View zeigt die Daten einfach an.