VIPER

Since much of the application logic does not belong in a model or view, it usually ends up in the controller.

Application Design Based on Use Cases

• Apps are often implemented as a set of use cases.
• Use cases are also known as acceptance criteria, or behaviors, and describe what an app is meant to do.
• A use case is the layer of an application that is responsible for business logic.

Main Parts of VIPER

The main parts of VIPER are:

View: displays what it is told to by the Presenter and relays user input back to the Presenter. Interactor: contains the business logic as specified by a use case. Presenter: contains view logic for preparing content for display (as received from the Interactor) and for reacting to user inputs (by requesting new data from the Interactor). Entity: contains basic model objects used by the Interactor. Routing: contains navigation logic for describing which screens are shown in which order.

Interactor

• An Interactor represents a single use case in the app.
• It contains the business logic to manipulate model objects (Entities) to carry out a specific task.

Entity

Entities are the model objects manipulated by an Interactor. Entities are only manipulated by the Interactor. The Interactor never passes entities to the presentation layer (i.e. Presenter).

Interactors should not work with NSManagedObjects.

Presenter

The Presenter is a PONSO that mainly consists of logic to drive the UI. It knows when to present the user interface. It gathers input from user interactions so it can update the UI and send requests to an Interactor.

Entities are never passed from the Interactor to the Presenter. Instead, simple data structures that have no behavior are passed from the Interactor to the Presenter. This prevents any ‘real work’ from being done in the Presenter. The Presenter can only prepare the data for display in the View.

View

The View is passive. It waits for the Presenter to give it content to display; it never asks the Presenter for data.

To keep our view controllers lean, we need to give them a way to inform interested parties when a user takes certain actions. The view controller shouldn’t be making decisions based on these actions, but it should pass these events along to something that can.

Routing

Routes from one screen to another are defined in the wireframes created by an interaction designer. In VIPER, the responsibility for Routing is shared between two objects: the Presenter, and the wireframe. A wireframe object owns the UIWindow, UINavigationController, UIViewController, etc. It is responsible for creating a View/ViewController and installing it in the window.

the Presenter will use the wireframe to perform the navigation.

It’s typically up to the Interactor to initiate a network operation, but it won’t handle the networking code directly. It will ask a dependency, like a network manager or API client. The Interactor may have to aggregate data from multiple sources to provide the information needed to fulfill a use case.