Как мы развиваемся с использованием архитектуры VIPER в iOS

Для борьбы с MVC (Mega-ViewControllers)

Парадигма MVC (модель-представление-контроллер) используется по умолчанию при разработке приложений для iOS. Однако этот стандартный «ViewController» портит представления и контроллеры. Разработчик обычно представляет как анимацию представления, так и бизнес-логику в одном UIViewController. Все это передается в MEGA-ViewController. Огромный ViewController фактически нарушает исходный дизайн MVC, согласно которому представления не должны иметь прямого доступа к моделям.

В этом посте мы поделимся своим опытом того, как VIPER спасает нам жизнь от монстра MVC в наших проектах. Во второй части мы также включили пример SignUpViewController.

Что такое VIPER?

Для приложений меньшего масштаба (с меньшим количеством взаимодействий с моделями и пользовательским интерфейсом) MVC не должны быть кошмаром. Однако представьте, что мы создаем немного более сложное приложение, которое включает несколько моделей и обновления пользовательского интерфейса в реальном времени. Это делает типичные контроллеры представления массивными и трудными для тестирования.

VIPER - это не фреймворк, а подход к архитектуре приложений iOS, который остается чистым со сложными приложениями. Это означает:

  • Вид
  • Interactor
  • Ведущий
  • Организация
  • Маршрутизация (каркас)

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

VIPER - это архитектура, основанная на Принципе единой ответственности. Вот как компоненты работают вместе для создания потока приложения:

ПОСМОТРЕТЬ

Представление должно состоять из представлений и контроллеров представлений. Он отвечает за получение взаимодействий с пользователем и передачу их докладчикам для принятия решений. Для простоты представление не должно содержать никакой логики представления. Здесь вы определяете, как выглядит представление, и ничего не включаете (БЕЗ проверки ошибок, НИКАКОЙ выборки данных), кроме внешнего вида представления.

ВЕДУЩИЙ

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

ВЗАИМОДЕЙСТВИЕ

Интеракторы в основном содержат бизнес-логику, такую ​​как вход пользователя, обработка покупки или отправка запроса на добавление в друзья. Он не должен зависеть от пользовательского интерфейса. Он обрабатывает только запросы от докладчика и подготавливает соответствующие данные независимо от того, как выглядит представление.

ОРГАНИЗАЦИЯ

Сущности - это объекты модели, которыми манипулирует Interactor и только Interactor. Это может быть просто NSManagedObject. Он ориентирован на модель и поэтому не должен содержать никакой бизнес-логики. Нельзя размещать что-то вроде [User loginWith: (NSString *) name password: (NSString *) password] внутри Entity.

МАРШРУТИЗАЦИЯ (WIREFRAME)

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

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

Чего нам помогает VIPER?

Быстрый ответ: VIPER разбивает сложные логические структуры на уровни с четко определенными обязанностями.

Если MVC - это мега-монстр, который вас беспокоит, VIPER - это небольшая коллекция монстров, которая помогает вам создавать приложения для iOS - более приятным и управляемым способом.

Теперь мы можем предотвратить рост Mega-ViewControllers и испортить нашу кодовую базу.

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

Часть вторая: пример RegistrationViewController

Чтобы проиллюстрировать, как мы работаем с VIPER, в этом примере мы хотели бы показать, как мы определяем компоненты для страницы регистрации.

Когда приложение запускается впервые, у нас есть RegistrationViewController в качестве rootViewController для AppDelegate.

Вид

Это показывает представление входа / регистрации. Он отвечает только за отображение элементов пользовательского интерфейса и получение взаимодействий.

Ведущий

@interface LoginPresenter
- (void)loginButtonTapped:(NSString *)email password:(NSString *)password;
@end
@protocol LoginPresenterProtocol
- (void)showErrorMessage:(NSString *)message;
@end

Interactor

@protocol LoginInteractorProtocol <NSObject>
- (void)requestSuccess;
- (void)requestFailed:(NSString *)errorMessage;
@end

@interface LoginInteractor : NSObject <ETRequestManagerProtocol>
- (id)init:(NSString *)email
password:(NSString *)password
delegate:(id<LoginInteractorProtocol>)delegate;
- (void)startRequest;
@end

Каркас

@interface WireFrame : NSObject
- (void)navigateToMainScreen;
@end

Если вы начинаете новый проект, вы также можете начать с некоторых генераторов VIPER с открытым исходным кодом:



pepibumur / viper-module-generator
viper-module-generator - Gem для создания модулей VIPER для использования их в ваших проектах Objective-C / Swift github. com





iSame7 / ViperCode
ViperCode - простое приложение OS X для создания скелета модулей VIPER для использования их в ваших проектах Objective-C / Swift. github.com



Контрольный список - убедитесь, что вы правильно внедрили VIPER

Этот список помогает убедиться, что все соответствует принципу дизайна VIPER. Мы надеемся, что это будет так же полезно для вас, как мы.

  • Представления и контроллеры представлений получают информацию о взаимодействиях пользователей и передают их докладчикам для принятия решений.
  • Презентаторы содержат логику просмотра и подготавливают контент для отображения и реакции на вводимые пользователем данные.
  • Докладчики должны не знать о существовании всех UIViews
  • Интерактивные элементы содержат бизнес-логику и не должны зависеть от пользовательского интерфейса.
  • Сущности - это объекты модели, которыми манипулируют взаимодействующие.
  • Каркас - единственное место для определения экранной навигации и их анимации перехода.

ВЫВОД

Если вы также находите «монстра Mega-ViewController» кошмаром для вашего приложения iOS, VIPER может быть одним из возможных решений.

VIPER - это предлагаемая архитектура, в которой компоненты должны быть определены в соответствии с вашим собственным вариантом использования.

Мы продолжим делиться своим опытом в изучении интересных, но полезных инженерных технологий и инструментов в будущем. Дайте нам знать, каков ваш опыт работы с VIPER!

Создаете приложение? Наши бесплатные инструменты разработчика и серверная часть с открытым исходным кодом упростят вашу работу.