ВЫБОР АРХИТЕКТУРНОГО ПАТТЕРНА ПРИ РАЗРАБОТКЕ ПРИЛОЖЕНИЯ ДЛЯ IOS

В данной статье будет рассматриваться вопрос о выборе архитектуры в начале разработки мобильного приложения для iOS, будут описаны критерии, по которым разработчики выбирают ту или иную архитектуру, представлено обобщенное описание их реализации.

Существует большое множество архитектурных шаблонов iOS, однако быстро развивающееся цифровое пространство ставит разработчиков в затруднительное положение. Трудности заключаются в том, что необходимо учесть большое количество факторов, таких как: технологии разработки, совместимость устройств, решение проблем с навигацией, покрытие тестами, опыт разработчиков, которые будут участвовать в проекте. Тщательный подход к архитектуре – это то, что позволит команде разработчиков избежать многих трудностей. Так как если пренебречь проектированием дизайна архитектуры, то в какой-то момент в программном коде возникнет множество классов, включающие в себя десятки, а то и сотни методов, которые необходимо отлаживать, и поиск ошибок станет крайне трудоемким процессом.

Наиболее популярными архитектурными шаблонами в iOS являются: MVC, MVVM и VIPER. Сначала в статье будет краткий обзор этих паттернов, а затем сравнение их плюсов и минусов.

MVC (Model-View-Controller) – шаблон разработки в iOS, также рекомендуемый Apple шаблон. MVC состоит из трех компонентов:

• Model
• View
• Controller

Model – это место, где хранятся данные. Там находятся такие вещи как объекты модели, менеджеры или сетевой код.

View – слой представления. Внешний вид приложения. Классы этого слоя часто используются повторно, так как не содержат никакой логики.

Controller – является посредником между моделью и представлением, чаще всего их связь обеспечивается посредством шаблона делегирования. При классической реализации контроллер не будет знать конкретное представление, с которым он будет взаимодействовать. Вместо этого он будет работать лишь с абстракцией через протокол.

Использование MVC можно найти в библиотеке UIKit. Например, табличное представление. Существует компонент UITableView, а также интерфейс взаимодействия с ним UITableViewDelegate или UITableViewDataSource [3]. Если собрать вышеописанное воедино, то получится схема представленная на рисунке 1.

Рисунок 1. Обобщенная схема MVC

MVVM (Model-View-ViewModel) – шаблон дизайна, который является одним из наиболее распространенных. Он представляет из себя архитектуру из трех слоев:

• Model – данные, с которым работает приложение. Это структуры, классы, которые хранят данные, получаемые из сети или других источников данных.
• View – визуальная составляющая приложения. Обычно это классы, предоставляемые библиотекой UIKit.
• ViewModel – модель представления связывает модель и представление через механизм привязки данных. Например, для этого может использоваться инструменты из библиотеки RxSwift или другого реактивного фреймворка.

С годами популярность MVVM все больше растет, это обусловлено тем, что шаблон довольно прост в изучении, четко разделяет ответственность слоев, что позволяет упростить контроллер, а также повысить тестируемость всего кода. Также на популярность данного паттерна влияет то, что он не стоит на месте, а постоянно разрабатываются различные его реализации. Например, c добавлением координатора, или с использованием библиотеки RxSwift.

Следующий архитектурный паттерн, который будет рассматриваться – VIPER. Данная архитектура является прямым наследником Clean Architecture, которая была описана в Статье «The Clean Architecture» Роберта Мартина. На рисунке 3 будет представлена схема чистой архитектуры из первоисточника [1].

Рисунок 3. Схема Clean Architecture

Приступая к VIPER необходимо разобраться, что означает данная аббревиатура. VIPER означает следующее: View-Interactor-Presenter-Entity-Router. Если описывать все компоненты данной архитектуры коротко, то можно получить следующее:

• View – визуальная часть приложения, которая зависит от Presenter и передает входные данные в него, после чего получает выходные данные для отображения.

• Interactor – содержит бизнес-логику отдельного VIPER-модуля, получает запросы от Presenter и возвращает какие-либо данные.
• Presenter – промежуточное звено между View и Interactor, реагирует на события из View, передает их в Interactor, затем получает данные в сыром виде и конвертирует их в данные для View.
• Entity – сущность, её можно сравнить с моделью данных из MV(X) паттернов.
• Router – слой, отвечающий за навигацию между VIPER-модулями.

По мнению многих разработчиков данная архитектура является наиболее строгой, однако у этого есть преимущества. К примеру, при использовании данного подхода код будет соответствовать как минимум одному из принципов SOLID - принципу единой ответственности. Это обеспечивается за счет довольно сильного распределения обязанности между слоями.

Теперь, после того как были описаны основные архитектурные шаблоны для разработки мобильных приложений для платформы iOS будут представлены их плюсы и минусы.

Начиная с MVC можно сказать следующее: плюсами концепции является то, что приложение написанное при ее помощи будет иметь глобальную общую архитектуру. Это позволяет программистам легко ориентироваться в программных блоках. Еще одно из положительных качеств такого подхода – скорость реализации. Например, программисту не составит труда добавить еще одно представление в приложение. Однако всех перечисленных плюсов можно не заметить, что случается довольно часто. В сообществе iOS-разработчиков нередко MVC расшифровывают как Massive View Controller. Дело в том, что, используя вариант MVC от Apple (Cocoa MVC) программист встретится с тем, что контроллер сильно вовлечен в жизненный цикл View. В конечном итоге программист получает ViewController, который является делегатом, источником данных, местом отмены серверных запросов. Коротко говоря – класс получает большое количество ответственности, что вредит поддержке кода, его отладке, а также покрытию тестами. Вместо схемы представленной на рисунке 1 получается несколько другая, где View и Controller являются практически единым модулем (рис. 4).

Рисунок 4. Massive View Controller

Далее рассмотрим MVVM. Плюсом данной технологии будет являться двусторонняя связь между моделью и моделью представления. Представление будет автоматически обновляться, и модель представления также будет автоматически обновляться, что обеспечивает хорошую согласованность данных. Однозначно к преимуществам можно отнести заметное уменьшение кода во ViewController. Также шаблон обеспечивает хорошую тестируемость и прозрачность кода. В целом MVVM имеет средний порог входа, в нем не так сложно разобраться, что тоже можно отнести к плюсам, но это не является постоянным преимуществом.

К минусам можно отнести связывание данных. Это может вызывать сложности с отладкой, так как ошибка может быть как в представлении, так и модели представления. Еще одним минусом является то, что двусторонняя привязка ограничивает программиста в повторном использовании кода. Последний недостаток – трудности в тестировании реактивного кода. Часто в качестве инструмента для связывания View и ViewModel используют реактивные фреймворки, что определенно усложняет тестируемость кода, хотя и не делает это невозможным.

К основным преимуществам VIPER следует отнести:

• Высокий процент тестируемости кода.
• Полная независимость модулей – это позволяет разрабатывать их независимо друг от друга.
• Передача проекта другим разработчикам, либо внедрение нового – несложная задача. Так как общие подходы к архитектуре известны.

К минусам такой архитектуры можно отнести:

• Резкое увеличение классов в проекте.
• Некоторые из принципов не ложатся на UIKit и подходы Apple.
• Отсутствие в открытом доступе конкретных рекомендаций и примеров реализации больших проектов.

Подводя итоги, можно сказать, что выбор архитектуры является долгой и ресурсоемкой задачей. Это решение необходимо принимать после взвешивания всех плюсов и минусов различных архитектур. Однако некоторые обобщенные выводы все же можно сделать. Если стоит задача сделать небольшой проект, то стоит посмотреть в сторону MV(X) паттернов. Либо же, если наоборот, стоит задача написать большой проект с огромным количеством функционала, или есть строгие требования к тестированию кода, то можно присмотреться к VIPER. Многие опытные разработчики отмечают, что приложение может совмещать в себе несколько подходов. Например, если была начата разработка с MVC, но в какой-то момент один из экранов стало сложно поддерживать с MVC, то нет ничего плохого, если конкретно этот экран будет переведен на MVVM, и при этом нет необходимости проводить рефакторинг остального приложения под MVVM, если другие экраны хорошо работают на MVC [2].

Список литературы:

1. Роберт С. Мартин. Чистая архитектура. Санкт-Петербург: Питер, 2018. 352 с.
2. Блог компании Badoo [Электронный ресурс]. – Режим доступа: https://habr.com/ru/company/badoo/blog/281162/. (дата обращения: 16.12.21)
3. Блог компании КРОК [Электронный ресурс]. – Режим доступа: https://habr.com/ru/company/croc/blog/549590/.  (дата обращения: 16.12.21)