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||Renders data||Performs queries to the Model|
|Raising appropriate events||Receives events||Formats data from Model|
|Very basic validation logic||Sends formatted data to the View|
|Complex validation logic|
Differences between 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.