Build with VIPER Architecture
Should i switch into VIPER ? is it worth ? Let’s see how it goes.
There are many architectures that make us confused about which architectures should be used likes MVC, MVP, MVVM, VIPER and many more. An architecture greatly affects the development process likes debugging, bug fixing, system organizing and data flow.
A good architecture must be testable, easy to use (low effort implementation and maintenance) and well informed (more clearer application flow).
One of the many architecture that we have ever known, let’s focus on VIPER. VIPER is a pattern that adaption of Clean Architecture that divides an app logical structure into layers. This makes it easier to isolates dependencies and testable for each interactions.
The main parts of VIPER:
- View represent as displays from the Presenter and giving the input to the Presenter.
- Interactor represent as business logic that contains specified case.
- Presenter represent as communicator between View and Interactor.
- Entity represent as model object that used by the Interactor.
- Router represent as navigation logic for describing which screens are shown.
There are main parts that we should known to build using VIPER. This separation conforms the Single Responsibility Principle. It makes an application becomes more modular and focus on each other tasks. Besides that, unit test become more clearer and testable because of using protocol to communicate each layer.
Implementation of VIPER
I used this structure for organize files and code into more specifically.
As you can see, we will create a VIPER pattern like the picture above. Why ? Because VIPER modules are connected to each other so it will be raised strong reference and makes our app into leaks.
View
View contains an action from Presenter and the View must do that action in the ViewController. Don’t forget, ViewController must called Event to connected with Presenter.
Interactor
Interactor contains a business logic, network call, fetch or load entities and many more. After finishing the process, Interactor must notified into presenter for the output.
Presenter
Presenter represented as communicator and decision maker. Presenter will tell to the Interactor for processing a business logic. After Interactor giving an output, Presenter will tell to the view for the action. Besides that, Presenter can communicate to the router regarding the navigation.
Entity
Entity contains a data object.
Router
Router will decide which view it should be navigate and loaded what module will shown.
Conclusion
The impression of using VIPER is too much classes for building the skeleton, where is an overkill for build a small application. But, VIPER is the best choices for who needs more modular, testable, scalable and contains S.O.L.I.D principles. I strongly recommend you to try VIPER because the development process will be more clearer.
To decide which architecture will be used, we need to make list of strengths and weaknesses for each architecture and then compare with our problem into some cases.
I have create a detailed implementation of VIPER Architecture. So you can download the completed project at:
