Изучите основы чистой архитектуры Swift за короткое время.

Помните те дни, когда мы, разработчики iOS, часами и днями изучали MVVM? Теперь я верю, что когда-нибудь, рано или поздно, мы будем искать везде, где можно изучить и освоить Чистую архитектуру.
Так почему бы нам не начать сегодня?

В этой статье я расскажу вам, что такое чистая архитектура, таким образом, чтобы вы могли быстро узнать о ней много нового.

So…

О чистой архитектуре Swift

Clean Swift (сокращенно VIP) — это чистая архитектура дяди Боба, адаптированная для проектов iOS и macOS. Архитектура VIP для написания чистого кода Swift была представлена ​​Рэймондом Лоу.
Как вы, возможно, знаете, VIP означает View — Interactor — Presenter.

Структура проекта в этой архитектуре построена вокруг сцен. Сцена должна иметь следующие компоненты:

  • Просмотр контроллера
  • Интерактор
  • Ведущий
  • Рабочий
  • Модели
  • Маршрутизатор
  • Конфигуратор (опционально)

Другими словами, у нас будет набор компонентов для каждой сцены, которые будут работать для нашего контроллера.

VIP-цикл

  1. Контроллер представления принимает пользовательское событие, создает объект запроса и отправляет его интерактору.
  2. Интерактор выполняет некоторую работу с запросом с помощью воркеров, создает объект ответа и отправляет его презентатору.
  3. Ведущий форматирует данные в ответе, создает объект модели представления и отправляет его в контроллер представления.
  4. Контроллер представления отображает пользователю результаты, содержащиеся в модели представления.

Теперь давайте рассмотрим каждый компонент глубже:

Просмотр контроллера

Общайтесь с Interactor и получайте ответ от докладчика.

  • Содержит представления.
  • Сохраняет экземпляры интерактора и маршрутизатора.
  • Передает действия из представлений в интерактор (бизнес-логика) и принимает действия докладчика в качестве входных данных.

Интерактор

Посредник между работником и ведущим.

  • Содержит бизнес-логику сцены.
  • Сохраняет ссылку на докладчика.
  • Запускает действия над рабочими процессами на основе ввода (из контроллера представления), запускает и передает результат презентатору.
  • Интерактор никогда не должен импортировать UIKit.
  • Interactor также содержит два типа протоколов, как и Router:
    1. Business Logic Protocol—объявите все методы Interactor в этом протоколе, чтобы они могли быть доступны для использования в ViewController.< br /> 2. Протокол хранилища данных — здесь объявляются все свойства, которые должны сохранять свое текущее состояние. Этот протокол в основном используется в маршрутизаторе для передачи данных между контроллерами.

Ведущий

Отформатируйте результат интерактора в ViewModel и передайте результат обратно в контроллер представления.

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

Работник (ы)

Обрабатывает все запросы и ответы API/базы данных.

  • Абстракция, которая обрабатывает различные скрытые операции, такие как извлечение пользователя из Core Data, загрузка фотографии профиля, предоставление пользователям возможности ставить лайки и подписываться на них и т. д.
  • Должен следовать принципу единой ответственности (интерактиватор может содержать множество работников с разными обязанностями).

Модели

Храните все модели данных.

  • Развязанные абстракции данных.
  • Содержит модели данных Request, Response и ViewModel.
  • Иногда запрос может быть пустой структурой (например, когда у нас нет никаких параметров публикации или запросов к БД).
  • Каждая модель данных предназначена для создания и использования в определенном компоненте:
    Request: создается в контроллере представления и используется в интеракторе.
    Response: создается в интеракторе и используется в презентаторе.
    ViewModel: Создается в презентере и используется в контроллере представления.

Маршрутизатор

Заботится о переходе и передаче данных между контроллерами представления.

  • Извлекает логику навигации из контроллера представления.
  • Сохраняет слабую ссылку на контроллер представления.
  • Объявлено два протокола:
    1. Протокол логики маршрутизации—все методы, используемые для маршрутизации, поддерживаются этим протоколом.
    2.Передача данных Протокол — протокол, содержащий данные, которые необходимо передать целевому контроллеру.

Конфигуратор

Принимает необработанный контроллер представления и возвращает настроенный контроллер представления.

  • Дополнительный компонент, который берет на себя ответственность за настройку цикла VIP, инкапсулируя создание всех экземпляров и назначая их там, где это необходимо.

Если вы читали примеры кода в этой статье, то могли заметить, что у нас есть еще один объект с именем SceneFactory.
SceneFactory — это не что иное, как класс, который хранит экземпляры конфигураторов сцен и создает сцены с их использованием.

Наконец, для файловой структуры вашего проекта вы можете следовать следующей схеме:

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

Спасибо за прочтение. Надеюсь, тебе понравилось!