Why should we use VIPER design pattern?

Introduction of four commonly used design patterns

1. MVC : M — Model, V — View, C — Controller

2. MVP : M — Model, V — View, P — Presenter

3. MVVM: M — Model, V — View, V — ViewModel

4. VIPER: V — View, I — Interactor, P — Presenter, E — Entity, R — Router

MVC:

MVC architecture was proposed by Apple and it works in good way for lots of small application. It is always good for initial phase of learning to iOS development.

The View part is responsible for displaying everything for system’s user (interfaces of mobile or web app, etc.).

Model is generally responsible for the databases, business entities and rest of data.

In its turn, Controller regulates the Model’s work, data provided to the database, display from the mentioned database to the View part and vice versa.

If you call an API endpoint using URLSession or Alamofire from the controller, do the response data validation and formatting then you implement your table or collection view delegates on the view controller, you also write some code to customise view component if its needed. So basically all the application logic goes inside that single view controller class and it results a massive view controller.

Developing a big project using purely MVC is not a good idea. One can not distinguish and separate the business and UI code.

MVC

MVP:

The model-view-presenter software pattern originated in the early 1990s at Taligent, a joint venture of Apple, IBM, and Hewlett-Packard.

• The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
• The view is a passive interface that displays data (the model) and routes user commands to the presenter to act upon that data.
• The presenter contains the UI business logic for the View. All invocations from the View delegate directly to Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test.View is more loosely coupled to the model.
• You will write a lot of codes for Presenter and they are logically related in which you will find it difficult to break down.

MVP

MVVM:

MVVM was invented by Microsoft architects Ken Cooper and Ted Peters specifically to simplify event-driven programming of user interfaces.

MVVM facilitates a separation of development of the graphical user interface code from development of the business logic or back-end logic . The view model of MVVM is a value converter, meaning the view model is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the view model is more model than view, and handles most if not all of the view’s display logic. The view model may implement a mediator pattern, organising access to the back-end logic around the set of use cases supported by the view.

• The model is an interface defining the data to be displayed or otherwise acted upon in the user interface. refers either to a domain model, which represents real state content , or to the data access layer, which represents content.
• View as in the model-view-controller (MVC) and model-view-presenter (MVP) patterns, the view is the structure, layout, and appearance of what a user sees on the screen. It displays a representation of the model and receives the user’s interaction with the view (clicks, keyboard, gestures, etc.), and it forwards the handling of these to the view model via the data binding (properties, event callbacks, etc.) that is defined to link the view and view model.
• The view model is an abstraction of the view exposing public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder, which automates communication between the view and its bound properties in the view model. The view model has been described as a state of the data in the model.

The main difference between the view model and the Presenter in the MVP pattern, is that the presenter has a reference to a view whereas the view model does not. Instead, a view directly binds to properties on the view model to send and receive updates. To function efficiently, this requires a binding technology or generating boilerplate code to do the binding.

Debugging would be bit difficult when we have complex data bindings.

MVVM

Viper

In case of bigger and complex project, it is required to handle many use cases in a clean and consistent manner. And to solve our problem for such bigger projects, VIPER got introduced.

The VIPER architecture is based on the single responsibility principle (S.O.L.I.D.) which leads us to the theory of a clean architecture.

Clean Architecture divides an app’s logical structure into distinct layers of responsibility.

Using this architecture one can easily test at the boundaries between each layers. One feature, one module. For each module VIPER has five (sometimes four) different classes with distinct roles. VIPER makes the code easier to isolate dependencies and to test the interactions at the boundaries between layers:

Components of VIPER:

View: Class that has all the code to show the app interface to the user and get their responses. Upon receiving a response View alerts the Presenter.

Interactor: It is the brain of project and has all the business logics of an app. Primarily make API calls to fetch data from a source. Responsible for making data calls but not necessarily from itself.

Presenter: Nucleus of a module. It gets user response from the View and work accordingly. Only class to communicate with all the other components. Calls the router for wire-framing, Interactor to fetch data (network calls or local data calls), view to update the UI. Its totally independent from UIKit.

Entity: Contains plain model classes used by the interactor.

Router: Does the wire-framing. Listens from the presenter about which screen to present and executes that.

Why to choose VIPER for your project:

1. To make the structure more modular.
2. To build the application on the Single Responsibility Principle.
3. To reduce the load and dependency on controllers.
4. To build the app on basis of use cases or behaviour based.

VIPER

Project Flow:

View — >Presenter : View communicates with the Presenter regarding all the user interactions and asks the presenter to perform necessary handlings regarding the same.

Presenter —> Interactor: Presenter communicates with Interactor(The brain of the module) regarding user actions or data fetching actions.

Interactor <— Presenter: Interactor communicates with the presenter regarding the output of the business logic which has performed the necessary actions.

Presenter —> View

Presenter communicates with the view to make the necessary UI changes with the results from the Interactor.

Presenter —> Router

Presenter communicates to router regarding navigation between pages.

Sample project using VIPER for iOS Swift:

You need not to worry about adding files manually, you can simply do it using Generamba (a code generator plugin for xcode).

We will show list of product Category with their respective products. Project will have two modules one Category and another product Module.

We use protocols to define the methods that a module component can call from other components on the same module. All the communications in the project are usually made using protocols and delegates.

Get source code from here: PSViperDemo.

Memory management

• The router keeps a weak reference of the view and the presenter.
• The presenter holds the router and the interactor strongly
• The interactor keeps a weak refernece of the presenter
• The view keeps a strong refernece of the presenter
• UIKit holds the views.

Thing to keep in mind while writing code:

First point is one should not make any class very massive, it will be a big challenge when another developer comes and do debugging for fixing a bug.

Code should always be written in such a way that if anyone visit your code can easily perform unit testing, debugging and bug fixing. Main concern is about reusability, maintainability and testability. The correlation of ‘testability’ to good design can be observed by seeing that code that has weak cohesion, tight coupling, redundancy and lack of encapsulation is difficult to test.

We can also add a separate module by using dependency injection for all the external services. It can also build mock or other versions of the same module. That’s quite helpful if it comes to unit testing.

All members of development team will know where to look for if a specific issue occurs. If it’s a view issue, you have to fix the view, if it comes to a navigation problem then it’s a router problem.

Wrapping up

VIPER is a really cool project architecture pattern among others, like MVP and MVVM. Although Viper is complex, it is best to choose for bigger project. It’s easier to write automated tests , since your UI logic is separated from the business logic. VIPER is good for Scalability, Reusability, Consistency, Clarity and Testability. At the same time VIPER can be an overkill for small projects that do not intend to scale.