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

Варианты

• MVC (Apple-style)

• MVP

• MVVM

MV(C/P/VM ) подходы• Model - предметные сущности или уровень доступа к данным (классы “Person” или “PersonDataProvider”)

• View - уровень представление (всё, что начинается с UI-)

• Controller/Presenter/ViewModel - “клей” или медиатор, который связывает между собой View и Model

• много не структурированного кода

• монстр-файлы (+1000 строк)

• чрезвычайная сложность

• код не тестируем

MVC “в стиле Apple”

Зачем думать об архитектуре?

• сбалансированное распределение ответственностей между сущностями со строго определенными ролями

• тестопригодность

• скорость внедрения и легкость поддержки существующего кода

Clean architecture

Clean architecture

• независима от фреймворков

• тестируема

• независима от UI

• независима от базы данных

• независима от внешних сущностей

VIPER

Что такое VIPER?

• View

• Interactor

• Presenter

• Entity

• Routing

Viewотвечает за отображение данных на экране и оповещает

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

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

работы текущего модуля

Presenterполучает от View информацию о действиях

пользователя и преобразует её в запросы к Router’у, Interactor’у, а также получает данные от Interactor’а,

подготавливает их и отправляет View для отображения

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

логики

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

Основные принципы

• протоколы

• внедрение зависимостей

• разделение интерфейсов

Но…

Кое-что упустили

• Wireframe слишком много знает

• Interactor’ы все еще сложны

• ViewController’ы обрабатывают таблицы и коллекции

• общение между модулями

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

Проблема №1: Wireframe

• разделяется на две сущности: Router и Assembly

• Router - переходы между модулями

• Assembly - сборка модуля и проставление зависимостей

Проблема №2: Interactor

• вводится дополнительный слой сервисов

• каждый из сервисов отвечает за работу с определенным типом объектов модели

• Interactor становится фасадом для сервисов

Проблема №3: ViewControllers

• вынесение логики, не соответствующей роли View в отдельный слой объектов, которые называются DataDisplay

• эти объекты реализуют методы для UITableViewDelegate и UITableViewDataSource, а также их аналоги для коллекций

Проблема №4: Передача данных

• два выделенных протокола ModuleInput и ModuleOutput

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

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

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

• сервисы

• interactor’ы

• presenter’ы

• view

• router’ы

• assembly

Некоторые выводы

• более “лёгкие”, специфицированные классы

• отличная масштабируемость задач между разработчиками

• никаких отговорок по тестированию

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

–Альберт Эйнштейн

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

Ресурсы к ознакомлению

• architecture patterns

• objc.io/viper

• clean architecture

• rambler-viper

• viper

Вопросы?

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