iOS MVP Architecture

Help us to keep this website almost Ad Free! It takes only 10 seconds of your time:
> Step 1: Go view our video on YouTube: EF Core Bulk Extensions
> Step 2: And Like the video. BONUS: You can also share it!

Introduction

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.

Remarks

Components:

enter image description here

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

ModelViewPresenter
Communicates with DB layerRenders dataPerforms queries to the Model
Raising appropriate eventsReceives eventsFormats data from Model
Very basic validation logicSends 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

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.


Got any iOS Question?