VIPER Architecture
In software development we run into many problems. Code that is difficult to test, duplicated code or little to none separation are things that give me headache nearly everyday.
Patterns try to solve common problems for certain use-cases. Singleton is a simple example. It solves the problem that a class just has to have one state.
The difference between design patterns (like the singleton) and architectural patterns is that architectural patterns solve problems relating with the separation of concerns.
The Problem
We create amazing apps. And with amazing apps, amazing user interfaces and complex functionality. That means our features will get complex as they grow.
We have to think about how we get everything clear, extensible, maintable and understandable.
The solution
VIPER solves exactly this problem: It describes the responsibility of our parts and how they interact with each other.
I refactored my App PursCreate to VIPER and started using it in some other larger projects. And this is what I learned:
- Everything has it‘s specific place. You know exactly that a functionality musst be placed in the router or presenter for example.
- The structure got more complex but it‘s super easy to add new features and keep them decoupled from another
- I reduced side effects
- It was easier to write UnitTests for my business logic
Let me give a short description of the parts of VIPER:
View
When you launch your App the things you see is the view. It‘s that red button with corner radius and shadow or some gradient-colored pills.
Presenter
The presentation logic handles all actions that are needed in order to display all required information in the view (asks the Interactor for the data).
It also handles all user-interaction like present a new screen, visually enter the edit mode or a custom back-action.
Interactor
The Interactor contains the business logic or acts as a facade to it.
In my recent projects common use cases were CoreData access, filtering products in a product-list (shopping app) or fire HTTP-Requests.
Entity
Entities represent your DataModel. This might be a ManagedObjectModel (for CoreData) or a structure containing a HTTP-response.
Router
The Router handles all the display and navigation logic. For example when a user clicks a button:The presenter will call the router and say: displayMyView().
Why should I extract this simple logic?
Because it quickly grows.
In my App PursCreate I have the following case:
When you click on a cell, an overview of your goal appears. There are two goal types. So you have to determine wether it‘s a classic task or a streak.
Now the user can edit his goals. If he enters the edit mode you have to determine the types again but in this time open the edit for the corresponding task and not the overview.
When an app grows this part might get very complex.
Complexity
VIPER has many advantages. However it comes with a lot of complexity. This might result in unnecessary overengineering.
Our job as programmer is to decide which architectural pattern is the right one for our use case. Maybe MVC or MVVM is perfect for simple use cases. In more complex things VIPER benefits with its separation and scalability.
This article describes it perfectly. I highly recommend reading it:
Blurring the Lines Between MVVM and VIPER — Developer Mind — Medium
