In the first part, here, we toured MVC, MVP, and MVVM design patterns. This final part will explore the VIPER design pattern.
Lately, VIPER is treated as the extended version of MVVM which provides more modularity as compared to its contenders.
VIPER module separation
It basically comprises of —
View(Controller) which presents UI to the user and forwards the actions on UI to the Presenter to handle.
Presenter handles the UI actions sent by View. This handling is totally independent of the UI controls. In addition to this, Presenter takes help of the Interactor to process the model(Entity) if need be.
Interactor mainly contains the business logic and integrates with the other parts of the application. It also owns and manages the Entity.
Entity is just a dumb data structure to store data. As said, it is owned by the Interactor and concealed from the other modules.
Router is a special component in the VIPER architecture, which explicitly deals with the navigation actions coming from the Presenter. The router can very well inject the dependencies through the Presenter. Navigation (Wireframing) is the only responsibility that the Router takes care of.
As a good practice, iOS applications contain multiple storyboards, each representing the unique feature of the application. VIPER could very well be used in the same aspects. Instead of architecting a single screen, if a complete functionality, like creating a profile for the user, is architected through VIPER, the code will be finely modular and can be tested correctly. VIPER perfectly works in the direction of separating the responsibilities.
Separation of responsibilities makes TDD(Test-Driven-Development) easier. In VIPER, test cases can be written against the functionality provided by the Interactor, as the Interactor is the component that deals with the business logic.
With these benefits, it does come with the pain of writing too many classes and maintaining them. Also, forwarding the events in the hierarchy is a duplication sometimes. VIPER comes with a strict learning curve too. There is a huge difference between MVC and the VIPER.
In my recent visits to the dev conferences, I have seen many developers and tech leads experimenting with this pattern and in their experiences, they have been highly benefited from it. Watch this talk for one such experience.
Conclusion
The design is the evolving process and design patterns are the output of it. There is not a PERFECT design pattern that works for all the use-cases and hence we have so many alternatives available. It totally depends on us to think and decide, considering all the pros and cons. There is no obligation to use just one design pattern in the application, we can very well use a mix of all as per our need.