Very quick comparison between the most popular iOS application architectures (MVC, MVP, MVP) and introducing VIPER architecture with slight modifications of the canonical one.

1. VIPER
архитектура

2. Варианты
• MVC (Apple-style)
• MVP
• MVVM

3. MV(C/P/VM) подходы
• Model - предметные сущности или уровень
доступа к данным (классы “Person” или
“PersonDataProvider”)
• View - уровень представление (всё, что
начинается с UI-)
• Controller/Presenter/ViewModel - “клей” или
медиатор, который связывает между собой
View и Model

4. • много не структурированного кода
• монстр-файлы (+1000 строк)
• чрезвычайная сложность
• код не тестируем

6. MVC “в стиле Apple”

7. Зачем думать об
архитектуре?
• сбалансированное распределение
ответственностей между сущностями со
строго определенными ролями
• тестопригодность
• скорость внедрения и легкость поддержки
существующего кода

8. Clean architecture

9. Clean architecture
• независима от фреймворков
• тестируема
• независима от UI
• независима от базы данных
• независима от внешних сущностей

10. VIPER

12. Что такое VIPER?
• View
• Interactor
• Presenter
• Entity
• Routing

16. View
отвечает за отображение данных на экране и оповещает
Presenter о действиях пользователя. Пассивен, сам никогда
не запрашивает данные, только получает их от Presenter.

18. Interactor
содержит всю бизнес-логику, необходимую для
работы текущего модуля

20. Presenter
получает от View информацию о действиях
пользователя и преобразует её в запросы к Router’у,
Interactor’у, а также получает данные от Interactor’а,
подготавливает их и отправляет View для отображения

22. Entity
объекты модели, не содержащие никакой бизнес-
логики

24. Router
отвечает за навигацию между модулями

26. Основные принципы
• протоколы
• внедрение зависимостей
• разделение интерфейсов

27. Но…

28. Кое-что упустили
• Wireframe слишком много
знает
• Interactor’ы все еще сложны
• ViewController’ы
обрабатывают таблицы и
коллекции
• общение между модулями

29. Решение существует
rambler-style VIPER

31. Проблема №1: Wireframe
• разделяется на две сущности: Router и
Assembly
• Router - переходы между модулями
• Assembly - сборка модуля и проставление
зависимостей

33. Проблема №2: Interactor
• вводится дополнительный слой сервисов
• каждый из сервисов отвечает за работу с
определенным типом объектов модели
• Interactor становится фасадом для сервисов

35. Проблема №3:
ViewControllers
• вынесение логики, не соответствующей роли
View в отдельный слой объектов, которые
называются DataDisplay
• эти объекты реализуют методы для
UITableViewDelegate и UITableViewDataSource,
а также их аналоги для коллекций

36. Проблема №4: Передача
данных
• два выделенных протокола ModuleInput и
ModuleOutput

37. Очень много файлов

38. Кодогенерация
Generamba, VIPER gen, Boa

40. Тестирование
Моки наше всё

41. • сервисы
• interactor’ы
• presenter’ы
• view
• router’ы
• assembly

43. Некоторые выводы
• более “лёгкие”,
специфицированные классы
• отличная масштабируемость
задач между разработчиками
• никаких отговорок по
тестированию

44. Использовать VIPER или MV(C/P)?

45. –Альберт Эйнштейн
“Всё должно быть изложено так просто, как
только возможно, но не проще.”

46. Ресурсы к ознакомлению
• architecture patterns
• objc.io/viper
• clean architecture
• rambler-viper
• viper

47. Вопросы?

48. Спасибо за внимание!