2 min read

MVP (Model-View-Presenter)

Model-View-Presenter (MVP) is a derivation of the Model-View-Controller (MVC) architectural pattern, used mostly for building user interfaces. In MVP, the Presenter assumes the functionality of the "middle-man".

1. The Three Components

Model

The data layer. It is responsible for handling the business logic and communication with the database or network APIs. It is identical to the Model in MVC.

View

The user interface (UI). It displays data and captures user actions.

  • Passive Interface: In MVP, the View is often "passive". It should not contain any business logic. It simply exports methods like showLoading(), displayUser(user), or exposes events like onSaveClicked.

Presenter

The logic layer. It acts as a bridge between the Model and the View.

  • Responsibility: It retrieves data from the Model, formats it for display, and pushes it into the View. It also handles user input events forwarded by the View.

2. The Flow

  1. User interacts with the View (e.g., clicks "Login").
  2. View notifies the Presenter (e.g., calls presenter.login(username, password)).
  3. Presenter asks the Model to authenticate the user.
  4. Model returns the result to the Presenter.
  5. Presenter updates the View (e.g., calls view.showSuccess() or view.showError()).

3. MVP vs. MVC

The key difference lies in how the View gets updated.

  • MVC: The Controller updates the Model. The View observes the Model directly and updates itself when data changes. There is often a link between View and Model.
  • MVP: The View and Model are completely decoupled. They never talk to each other. The Presenter handles all communication. The View is strictly an interface implemented by the UI.

4. Variations

Passive View

The View is completely dumb. The Presenter updates every single widget on the screen.

  • Pros: Maximum testability (you can test the Presenter without any UI framework).
  • Cons: More boilerplate code.

Supervising Controller

The View handles simple data binding (like mapping a text field to a variable), while the Presenter handles complex logic.

5. Pros and Cons

Pros Cons
Testability: Since the View is just an interface, you can easily mock it and unit test the Presenter logic. Complexity: Adds more classes and interfaces than simple MVC.
Decoupling: Clear separation between UI and Logic. Boilerplate: Requires creating interfaces for every View.

programming/model-view-controller programming/clean-architecture programming/software-development-life-cycle