MVP Architecture

Components:

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

Component duties:

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.

Pros:

• 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.

Cons

• You will write more code.
• Barrier for unexperienced developers or for those who don’t yet work with the pattern.

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.