Viper
0 likes751 views
The document discusses V.I.P.E.R., an architectural pattern for mobile applications. It consists of View, Interactor, Presenter, Entity, and Routing components. The View displays data from the Presenter without directly requesting it. The Interactor contains business logic independently of the user interface. The Presenter handles displaying views and communicating between View and Interactor. Entities are basic data models changed only by Interactors. Routing manages screen navigation. V.I.P.E.R. allows for testability and cross-platform logic but adds complexity compared to simpler architectures.
Viper
- 2. M.V.C. • Majority of mobile applications. • Cons • Massive View Controllers • Hard to test • Duplicate Code Model View Controller
- 3. V.I.P.E.R. • View • Interactor • Presenter • Entity • Routing
- 4. View • Displays view data from the Presenter. • Never request data from the Presenter. • Relays interactions to the Presenter.
- 5. Interactor • Contains all business logic for a given use case. • All business logic should be independent of the user interface. • Interactors should be independent of OS ie iOS and Mac OS • Simple object make for easy testing.
- 6. Presenter • Contains logic for displaying view content. • Reacts to user interaction and communicates between the View and the Interactor. • Converts results from the Interactor to an object the can be displayed to the View. • Simple data structures should be the only thing passed from the Interactor to the Presenter ie Strings… • Simple object easy to test.
- 7. Entity • Basic model object. • Should only be changed by the Interactor and never passed to the Presenter. • Simple object make for easy testing.
- 8. Routing • Handles navigation logic for describing which screens are shown in which order. • Used to handle transitions from one view to another.
- 9. Datastore (Optional) • Handles retrieving and saving data to storage, such as database, online, memory, etc. • Handles conversion from entity to data record and data record to entity. • Should only be accessed by the Interactor. • Simple Object
- 10. Pros & Cons • Pros • Can easily be developed with TDD. • Easily testable • Allows for cross platform business logic and data storage. • Each object has a single responsibility. • Can be used along side Reactive frameworks.
- 11. Pros & Cons • Cons • Does not allow for fast prototyping. • Adds a layer of complexity to small or simple projects. • Can cause circular references, be mindful of strong references to other objects. • Can be difficult to understand.
- 13. Testimony
- 14. Q & A
- 15. Sources • Clean Architecture • https://blog.8thlight.com/uncle-bob/2012/08/13/the- clean-architecture.html • VIPER for iOS • https://www.objc.io/issues/13-architecture/viper/ • Clean Architecture Android • https://speakerdeck.com/richk/clean-android- architecture