MVP is an architectural pattern, a derivation of the Model–View–Controller. It's represented by three distinct components: Model, View and the Presenter.
It was engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic.
In examples you'll find a simple project built with MVP pattern in mind.
Model is an interface responsible for the domain data (to be displayed or otherwise acted upon in the GUI)
View is responsible for the presentation layer (GUI)
Presenter is the "middle-man" between Model and View. It reacts to the user’s actions performed on the View, retrieves data from the Model, and formats it for display in the View
Communicates with DB layer
Performs queries to the Model
Raising appropriate events
Formats data from Model
Very basic validation logic
Sends formatted data to the View
Complex validation logic
Differencesbetween MVC and MVP:
View in MVC is tightly coupled with the Controller, the View part of the MVP consists of both UIViews and UIViewController
MVP View is as dumb as possible and contains almost no logic (like in MVVM), MVC View has some business logic and can query the Model
MVP View handles user gestures and delegates interaction to the Presenter, in MVC the Controller handles gestures and commands Model
MVP pattern highly supports Unit Testing, MVC has limited support
MVC Controller has lots of UIKit dependencies, MVP Presenter has none
MVP makes UIViewController a part of the View component it's dumb, passive and...less massive ;]
Most of the business logic is incapsulated due to the dumb Views, this gives an excellent testability. Mock objects can be introduced to test the domain part.
Separated entities are easier to keep in head, responsibilities are clearly divided.
You will write more code.
Barrier for unexperienced developers or for those who don't yet work with the pattern.
This modified text is an extract of the original Stack Overflow Documentation created by following contributors and released under CC BY-SA 3.0