VIPER

View

Interactor

Presenter

Entity

Router

VIPER is a type of Clean Architecture you can use to structure your apps. It is argued that VIPER is especially useful when it comes to testing. Test-Driven-Development is a major mantra in iOS. VIPER adhered to the TDD format by allowing developers an easier way to isolate and debug their errors. I would also argue that VIPER promotes the SRP( Single-Responsibility-Principle)? Conceptually, VIPER divides up tasks to reduce complexity. The general idea is to reduce your app’s dependencies by balancing delegation responsibilities amongst entities.

MAIN PARTS OF VIPER:

· View — This is the interface layer incorporating the UIKit elements. The UIViewController’s subclasses should belong to the view layer in a more decoupled fashion. When thinking about the VIEW, VIPER is similar to MVVM, because views are responsible for displaying what the presenter asks them to , and then transmit the user input back to the presenter.

· Interactor — This contains the heart of the business logic. The interactor fetches data from the model (using network or local database), and its implementation is totally independent from the user interface. VIPER treats the network and database managers as separate dependencies because they are not part of VIPER.

· Presenter — The presenter contains the necessary logic to format the data that will be displayed. In MVVVM, the ViewModelController handles this logic. The presenter receives data from the interactor, instantiates a view model and carries it to the VIEW. Furthermore, it reacts to user inputs, asking for more data or sending it back to the interactor.

· Entity — Has part of the responsibilities of the model layer in the other architectures. Entities are plain data objects, with no business logic, managed by the interactor and by the data managers.

· Router — The navigation logic of the application. It might not seem like an important layer, but if you have to reuse the same iPhone views in a iPad application, the only thing that might change is the way that the views are presented. This lets your other layers remain untouched, and the Router is responsible for the navigation flow in each situation.

USE CASES:

· Working in small teams, new developer(s) that join can easily work on particular module and thus dividing up work is less of a nuisance.

· It’s easier to track issues via crash reports (due to the Single Responsibility Principle)

· Adding new features is easier

· The source code will be cleaner, more compact and reusable

· There are less conflicts with the rest of the development team

· It’s easier to write automated tests (!), since your UI logic is separated from the business logic.

DON’T USE:

There are a lot of elements involved causing an overhead on new projects. If you are working on a small project that’s not intended to scale, this may not be the best architecture for you. Simultaneously, everyone on your team needs to be on board or you’ll end up with a hybrid MVC-VIPER scenario, which is just as much of a headache.

Fuck the M(assive)VC.

As beginners too often we let our View Controller increase in lines, mass and sass. A downfall of the MVC is that, the VC’s responsibility becomes too loosely defined and thus leading it to have more than one responsibility.

Choose your architecture responsibly!