Viper Architecture - Rajeswarip1203/rajeswari GitHub Wiki

What is Viper?

Viper is a delegation driven architecture and this used to implement the ‘separation of concern’. Most of the communication between different layers execute through delegation. One layer calls another through a protocol. Calling layer calls a function from a protocol. Listening layer conforms to that protocol and implements the function.

VIPER has five different classes with distinct roles.

View

  • The class that has all the code to show the app interface to the user and get their responses. Upon receiving a response View alerts the Presenter.

Presenter

  • It gets user response from the View and works accordingly. The only class to communicate with all the other components. Calls the router for wire-framing, Interactor to fetch data (network calls or local data calls), view to update the UI.

Interactor

  • Has the business logic of an app. Primarily make API calls to fetch data from a source.

Router

  • Does the wire-framing. Listens from the presenter about which screen to present and executes that.

Entity

  • Contains plain model classes used by the interactor.

Onion Architecture

  • Most of the traditional architectures raise fundamental issues of tight coupling and separation of concerns.

  • Onion Architecture was introduced by Jeffrey Palermo to provide a better way to build applications in perspective of better testability, maintainability, and dependability.

  • Onion architecture layers interact with each other by using the Interfaces.

At the centre of Onion Architecture is the domain model, which represents the business and behaviour objects. Around the domain, the layer is other layers, with more behaviours.

What Architecture do we follow?

We have taken the good things from both VIPER and ONION and followed in our project.

Why we use this Viper + Onion Architecture?

  • Simplifies complex projects. Since modules are independent Viper is really good for large teams.
  • Makes it scalable. Enable developers to simultaneously work on it as seamlessly as possible
  • Decouples the code for reusability and testability
  • Divides the application components based on its role
  • Sets clear responsibilities, Viper is a champion in the distribution of responsibilities
  • Makes it easy to add new features
  • Makes it easy to write automated tests since UI logic is separated from the business logic
  • It encourages a separation of concerns that makes it easier to adopt TDD. The Interactor contains pure logic that is independent of any UI, which makes it easy to drive with tests
  • Makes it easy to use
  • Creates clear and well-defined interfaces, independent of other modules. This makes it much easier to change the way your interface presents various modules to the user.
  • Makes it easier to track issues via crash reports due to the Single Responsibility Principle
  • Makes the source code cleaner, more compact and reusable
  • Reduces the number of conflicts within the development team
  • Applies SOLID principles
  • Reduced number of merge conflicts
  • Makes codebase look similar. Becomes much faster-reading other people code.

What we achieved with this architecture:

  • We have successfully followed TDD with 1600+ tests
  • Have tested all screens and View (UI) using Snapshot Tests
  • We tried many modules plugged in or plugged out in few mins
  • New joinees in the team understood the code easily and loved the way it is organised