Straight to the point: VIPER architectural pattern
As part of my Individual Development Program (IDP), I have been dedicating myself to studying the theory behind the knowledge I have acquired throughout my career as an iOS developer. In search of theoretical grounding, I came across an incredible book on LinkedIn shared by a colleague from the same Swift developers group to which I belong.
In this article, I continue to explore the topic of the previously published article on the VIP architectural pattern. Despite the similarity between the contents, it’s worth checking out for a detailed evaluation of other architectural patterns and my learning journey.
VIPER
The View-Interactor-Presenter-Entity-Router (VIPER) pattern is a set of five design patterns that clearly defines the role of each component in a software project. These components are the View, Interactor, Presenter, Entity, and Router, and each one has specific rules and context of use to ensure their uniqueness and functionality within the project.
The Entity is responsible for the business logic, access, manipulation, and storage of application data. It encompasses classes related to data persistence, application communications, and parsing of external information. It is important to note that the Entity does not communicate with the View, being part of a sequence of processes performed between the View-Interactor-Presenter communication.
In the Clean architecture, the Entity may be present in various layers such as Use Cases (Domain), Repositories (Data), and Data Sources (Networking and Storage). Generally, the Entity is composed of objects that parse information, extensions, constants, and helper classes, and these objects can communicate with each other.
In the VIPER pattern, the Interactor plays a fundamental role in containing the application’s business logic. Unlike the View, it is independent and receives information from the Entity. When receiving actions from the Presenter, the Interactor processes the information and returns the result to the Presenter through a Delegate. It is important to emphasize that the Interactor preserves the separation of responsibilities and the cohesion of the VIPER pattern, never sending the Model to the Presenter without processing it based on the business rules.
The Presenter is the central component of the VIPER architecture. Its function is to act as a link between the different components of the pattern, receiving user interactions from the View and containing the logic to act on these interactions and request information from the Interactor. The information received from the Interactor is represented by simple data structures, without the need to manipulate the raw Entities.
Although the Presenter has no knowledge of the components that make up the View, it knows what content should be displayed and when. Additionally, it is responsible for passing information to the View in the most efficient way possible and manipulating navigation to other screens using the Router.
The View is composed of interface elements that are visible to the user, such as classes included in the UIKit library. The View is responsible for displaying the Model data, obtaining it through communication via the Presenter’s Delegate.
To maintain the implementation of the View, Presenter, and Interactor design patterns organized, the author established a set of protocols.
Protocols
- PresenterInput (View -> Presenter);
- PresenterOutput (Presenter -> View);
- InteractorInput (Presenter -> Interactor);
- InteractorOutput (Interactor -> Presenter);
Implementation
After absorbing the knowledge acquired through the recommended book and applying the development techniques that I use in my projects, I have created an implementation model that fits my reality. In this article, I will share a specific example of the implementation of the Interactor, Presenter, and the integration with the View, highlighting the techniques and resources that I used.
Presenter
Interactor
Thank you for reading this far!
If you would like to contribute so that I can continue producing more technical content, please feel free to buy me a coffee ☕️ through the Buy me a Coffee platform.
Your support is essential to maintain my work and contribute to the development community.