Viper architecture
-
Upload
instinctools -
Category
Mobile
-
view
337 -
download
1
Transcript of Viper architecture
![Page 1: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/1.jpg)
VIPERarchitecture
![Page 2: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/2.jpg)
Options
• MVC (Apple-style)
• MVP
• MVVM
![Page 3: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/3.jpg)
MV(C/P/VM) approaches
• Model – domain entities or data access layer (“Person” or “PersonDataProvider” classes)
• View – presentation tier (everything that begins with UI-)
• Controller/Presenter/View Model – “glue” or mediator that connects together View and Model
![Page 4: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/4.jpg)
• a lot of unstructured code
• monster files (+1000 lines)
• baffling complexity
• untestable code
![Page 5: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/5.jpg)
![Page 6: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/6.jpg)
"Apple-style" MVC
![Page 7: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/7.jpg)
Why should you think about architecture?
• balanced distribution of the responsibilities among entities with strictly defined roles
• testability
• implementation speed and support of the existing code
![Page 8: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/8.jpg)
Clean architecture
![Page 9: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/9.jpg)
Clean architecture
• independent from frameworks
• testable
• independent from UI
• independent from database
• independent from external entities
![Page 10: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/10.jpg)
VIPER
![Page 11: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/11.jpg)
![Page 12: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/12.jpg)
What IS Viper?
• View
• Interactor
• Presenter
• Entity
• Routing
![Page 13: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/13.jpg)
![Page 14: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/14.jpg)
![Page 15: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/15.jpg)
![Page 16: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/16.jpg)
Viewdeals with data presentation and notifies the Presenter about user’s actions. It’s absolutely passive, never asks for the data by itself, only receives it from the Presenter
![Page 17: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/17.jpg)
![Page 18: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/18.jpg)
Interactorcontains all business logic needed for a module
![Page 19: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/19.jpg)
![Page 20: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/20.jpg)
Presenterreceives information from View about user’s actions and transforms it into Router & Interactor requests as well as receives data from the Interactor, prepares it and sends
to View for displaying
![Page 21: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/21.jpg)
![Page 22: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/22.jpg)
Entitydomain models that don’t contain any business logic
![Page 23: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/23.jpg)
![Page 24: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/24.jpg)
Routerdeals with navigation between modules
![Page 25: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/25.jpg)
![Page 26: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/26.jpg)
Main principles
• protocols
• dependency injection
• interface segregation
![Page 27: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/27.jpg)
BUT…
![Page 28: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/28.jpg)
We’ve lost something
• Wireframe knows too much
• Interactors are still difficult
• ViewControllers process tables and collections
• doesn’t have well defined communication between modules
![Page 29: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/29.jpg)
There is a solutionrambler-style VIPER
![Page 30: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/30.jpg)
![Page 31: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/31.jpg)
Problem No 1: Wireframe
• splits up into two entities: Router and Assembly
• Router - transitions between modules
• Assembly – gets components together with dependency injection
![Page 32: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/32.jpg)
![Page 33: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/33.jpg)
Problem No 2: Interactor
• introduce the additional services tier
• each of the services is responsible for dealing with a certain type of domain models
• Interactor becomes a facade for services
![Page 34: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/34.jpg)
![Page 35: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/35.jpg)
Problem No 3: ViewControllers
• remove a logic which is not suitable to the View role into separate tier called DataDisplay
• these objects implement the methods for UITableViewDelegate and UITableViewDataSource as well as their versions for collections
![Page 36: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/36.jpg)
Problem No 4: Transferring data between modules
• two protocols ModuleInput and ModuleOutput
![Page 37: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/37.jpg)
a LOT of files
![Page 38: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/38.jpg)
Code generationGeneramba, VIPER gen, Boa
![Page 39: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/39.jpg)
![Page 40: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/40.jpg)
TestingsIt is all about mocks
![Page 41: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/41.jpg)
• services
• interactors
• presenters
• views
• routers
• assemblies
![Page 42: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/42.jpg)
![Page 43: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/43.jpg)
Some conclusions
• “lighter”, stricter classes
• excellent scalability of the tasks among developers
• no excuse for making tests
![Page 44: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/44.jpg)
VIPER vs. MV(C/P)
![Page 45: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/45.jpg)
–Albert Einstein
"Everything should be made as simple as possible, but no simpler"
![Page 46: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/46.jpg)
Resources
• architecture patterns
• objc.io/viper
• clean architecture
• rambler-viper
• viper
![Page 47: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/47.jpg)
Questions?
![Page 48: Viper architecture](https://reader031.fdocuments.in/reader031/viewer/2022021418/58847e1b1a28ab5e248b79df/html5/thumbnails/48.jpg)
Thank you!