The Model-View-Presenter (MVP) pattern
Pattern · Chapter 7
Overview
Section titled “Overview”- A variation on MVC; also separates UI logic from business logic.
- The Presenter takes the place of the controller.
- Each view typically has a corresponding view interface; presenters couple to that interface, so the view is more loosely coupled to the model (they never interact directly).
- Works for both web and desktop applications.
Components
Section titled “Components”| Component | Responsibility |
|---|---|
| Model | Business model and data; interacts with the database. Receives update messages from the presenter and reports state changes back to it. Never interacts with views directly — only the presenter. |
| View | Displays the UI and data; implements a view interface. Sends messages to the presenter to act on events/data. More passive — relies on the presenter for what to display. |
| Presenter | Intermediary between model and view; interacts with both. Notified of user actions, updates the model, receives model state changes, formats model data for the view. Encapsulates presentation logic (active role). |
Key distinction from MVC
Section titled “Key distinction from MVC”- In MVC a controller can drive multiple views; in MVP each presenter typically handles one and only one view.
- Views are more passive and the model-view coupling is looser (mediated by the view interface).
Related
Section titled “Related”Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.7 “The Model-View-Presenter pattern”, pp. 543-546.