What are the differences between the architectural patterns MVC and MVP?

MVC (Model-View-Controller) and MVP (Model-View-Presenter) are two popular architectural patterns designed to divide an application into components for improved maintainability and testability. The key differences lie in the distribution of responsibilities and interactions between components.

MVC (Model-View-Controller):

• Model: Contains the application's data and business logic. It is not notified about the View or Controller.
• View: Displays data from the Model and handles user actions (e.g., button presses). The View is directly connected to the Model (pulls data from it).
• Controller: Acts as an intermediary between the Model and View. It receives user actions from the View, updates the Model, and selects the View for display.

In MVC, the View and Controller are closely linked. The View can directly access the Model for data, which can complicate testing the View. The Controller updates the Model, which in turn notifies the View of changes (often via KVO or NotificationCenter).

MVP (Model-View-Presenter):

• Model: Similar to the Model in MVC, contains data and business logic.
• View: Displays data and forwards all user actions to the Presenter. The View is a passive entity that does not contain business logic and does not interact directly with the Model.
• Presenter: Acts as a controller but with a different responsibility. It receives user actions from the View, interacts with the Model to update data, and then updates the View by calling its methods. The Presenter knows about the View and the Model.

In MVP, the View is completely separated from the Model. The Presenter acts as an intermediary, handling the logic between the View and the Model. The Presenter updates the View by "pushing" data to it. This makes the View more "dumb" and allows easier testing of the Presenter in isolation.

Comparison table:

Attribute	MVC	MVP
View's connection to Model	View can access the Model	View does not know about the Model
Main linking role	Controller	Presenter
View update mechanism	Model notifies View (Pull)	Presenter updates View (Push)
"Intelligence" of View	Can contain display logic	Passive, contains minimal logic
Testing	Testing the View can be more difficult	Testing the Presenter is easier
Dependencies	Controller depends on View and Model	Presenter depends on View and Model

Simplified interaction example:

MVC:

1. User presses a button in the View.
2. The View notifies the Controller.
3. The Controller processes the action, possibly updating the Model.
4. The Model notifies the View of data changes.
5. The View updates its interface, retrieving data from the Model.

MVP:

1. User presses a button in the View.
2. The View forwards the action to the Presenter (e.g., calls a method in the View protocol).
3. The Presenter processes the action, interacts with the Model.
4. The Presenter receives updated data from the Model.
5. The Presenter updates the View by calling its methods (e.g., view.display(updatedData)). The View simply displays the data.