Home
VIPER is an architecture pattern based on Clean Architecture. The word VIPER is a backronym for View, Interactor, Presenter, Entity and Routing. This divides an app’s logical structure into distinct layers of responsibility. Clean Architecture was proposed by Robert C. Martin (aka Uncle Bob) which is a combined version of Hexagonal Architecture and Onion Architecture.
The concentric circles represent different areas of software. The further in we go, the higher level the software becomes. The various components follow the Dependency Rule to maintain proper boundary among themselves.
Source code dependencies must point only inward, towards higher-level policies.
In other words, nothing in the inner circle(the higher component) can know anything at all about somethings in the outer circle(the lower component).
Entities encapsulate enterprise-wise Critical Business Rule. They are meant to be used by many different applications in the enterprise. An entity can be an object with methods, or it can be a set of data structures and functions. In case of mobile applications, we have just one single application. In this case the entities represent the business objects of the application. This objects should be affected by the changes in UI layer or any other lower level layers.
Usecases encapsulate application-specific business rules. They coordinate with the entities to apply Critical Business Rule. Let’s take an example. Suppose we are building a signup flow. Here one use case would be “User should be able to sign up”. Now the signup involves different objects to be validated. Those validation rules are specified in entities. Whereas Signup method is the part of usecase layer which uses the entities to achieve the goal.
They convert data from the format most convenient for the usecases and entities, to the most convenient for some external agency such as database and web. This layer contains the whole of the MVC architecture of a GUI. The presenters, views and controllers all belong in this layer. In case of iOS Architecture, we have the following things in this layer.
- ViewControllers
- Presenters
- Gateways : Interface to database layer, Interface to server
This layer generally contains the system framework. Here lies the UIKit, Coredata etc.
- Classes marked with (I) are interfaces.
- Classes marked with (DS) are data structures.
- Open arrow heads are using relationships. A -> B : Code of class A mentions the name of class B, but class B mentions nothing about class A.
- Closed arrow heads are implements or inheritance relationships.
All component relationships are unidirectional.
Let us consider a case of a typical web based java application and understand how data flow across the boundaries.
- Data flow from Controller to Interactor
The web server gathers data from the user and hands it to the Controller. Then the Controller passes the data in a plain object to the Interactor through InputBoundary. If we follow the diagram above, both Interactor and Controller use the data structure InputData. According to the Dependency rule, the higher level module should not depend on the lower level module. Interactor should not have a reference to the Controller. Here Dependency Inversion principle is applied. An interface InputBoundary is defined which is implemented by Interactor.
- Data flow from Interactor to Presenter
The Interactor coordinates with Entity, DataStore and Webservices and passes the data in a plain object to the Presenter through OutputBoundary. The Presenter implements OutputBoundary protocol. Both Interactor and Presenter use the data structure OutputData.
- Data flow from Presenter to View
The Presenter formats the data received from Interactor in the form of ViewModel which represents information needed to be displayed in the view. This does not contain any business rule.
Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)