Model-View-Presenter (MVP) is a derivative of the Model-View-Controller (MVC) architectural pattern, and is used mostly for building user interfaces. Like MVC, it also separates the application's concerns into three parts: Model, View, and Presenter.
Here's what each component does in the MVP pattern:
Model: Like in MVC, the Model in MVP represents the data and business logic of the application. It's responsible for fetching data, storing it, and any changes to it.
View: The View in MVP is responsible for displaying the UI and receiving user inputs. However, unlike MVC, it also defines a way to communicate with its Presenter. The View and Presenter are usually defined with a contract/interface to help achieve this. The View informs its Presenter about any user interaction and the Presenter decides what to do next.
Presenter: The Presenter acts as the middle-man between the Model and the View. It retrieves data from the Model, manipulates it, and returns it to the View. It responds to user interactions passed on from the View and updates the data in the Model, if necessary. The Presenter holds a reference to the View, but it doesn't communicate directly with it (like the Controller in MVC). Instead, it uses the interface defined by the View.
One of the key distinctions of MVP from MVC is that the Presenter contains the UI business logic for the View, and it's also responsible for deciding what happens when you interact with the View. Instead of having the Controller decide what to do next, the Presenter is making this decision in MVP.
The advantage of MVP is that it allows for greater separation of concerns and makes testing easier, because the Presenter can be unit tested independent of the View.