# 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]]