Всем привет, меня зовут Юрий Трыков, я Head of Mobile в inDriver. В этой статье расскажу, как в рамках платформенной iOS-команды мы выстраивали модуляризацию DI-контейнеров в проекте, зачем вообще нам нужны DI-контейнеры и как настраивать взаимодействие UDF-компонентов и DI-контейнеров. Приятного чтения!

Зачем нужны DI-контейнеры в больших проектах?

Одна из целей — реализация процесса внедрения зависимостей и принципа инверсии управления зависимостями. Она, в свою очередь, оказывает позитивное влияние на проект, уменьшая связанность между компонентами и модулями.

Еще одна цель кроется в удобстве для разработчиков. Ни один крупный проект не обходится без модуляризации. Модуляризация проекта позволяет изолировать предметную область приложения для переиспользования и комфортной работы команд. Модули могут разбиваться по разными принципам. Для упрощения представим, что есть только feature- и core-модули.

Модули могут иметь сложный граф. Чтобы собрать верхнеуровневую сущность feature-модуля (например, фасад), приходится использовать нескольких дочерних сервисов, которые могут иметь свои зависимости из core-модулей. Чтобы достать зависимость из feature-модуля, разработчику достаточно одной строчки.

Внедрения зависимостей (Dependency Injection):

- через конструктор;

- через функцию;

- через переменную.

Инверсия управления зависимостями (Dependency Inversion Principle — DIP):

- Модули верхнего уровня не должны зависеть от модулей нижнего уровня и наоборот. Модули должны зависеть от абстракций.

- Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Выбор DI-контейнера в iOS

Сначала необходимо определиться с выбором фреймворка и критериями, удовлетворяющими целям проекта. В контексте платформенной команды крайне важно уменьшать TTM, не допускать дублирования кода и предоставлять удобные инструменты для разработчиков. Для себя мы определили следующие критерии:

• Поддержка иерархии контейнеров и возможность разделить assembly.

• Минимальное время получения зависимости при максимальном числе регистраций зависимостей в контейнере.

• Thread safety.

DI-фреймворки:

• Swinject

• Dip

• Needle

• Dittranquikity

• EasyDI

• Cleanse

Выбор фреймворка

Фундаментальную работу проделали коллеги из финтеха. Они протестировали все фреймворки, поэтому нам осталось лишь валидировать результаты и проанализировать соответствие критериям. После валидации критериев и результатов тестов scope фреймворков сузился до Swinject и Needle.  

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

Мы осознавали риски преждевременной оптимизации и сложность переключения подходов в долгосрочной перспективе для проекта и команд. А кроме того, понимали все плюсы и минусы различных подходов — Compile Time vs. Runtime, Service Locator vs. Reflection и так далее.

Кстати, напишите в комментариях, каким фреймворком пользуетесь (или не пользуетесь) и почему?

Модули и DI

Приступая к организации DI-контейнера в многомодульном проекте, нужно решить вопрос с доступностью core-модулей для feature-модулей.

Решения на примере Swinject

Для реализации можно смотреть в сторону паттерна composition root.

Давайте посмотрим, как это выглядит на практике. Для этого немного погрузимся в контекст Swinject:

Assembler — отвечает за управление инстансами Assembly и контейнером. Предоставляет доступ для зарегистрированных сущностей в Assembly через протокол Resolver.

Assembly — протокол, который предоставляет общий контейнер для регистрации сущностей. В контейнере находятся все сущности из каждого Assembly.

Создаем корневой Assember и добавляем туда все core-компоненты.

// Composition Root Assembler of application
final class MainAssembler: NSObject {
  
   // MARK: - Singleton
   static let shared = MainAssembler()

   // MARK: - Variables
   private(set) var assembler: Assembler

   private init(
       _ assembler: Assembler = Assembler()
   ) {
       self.assembler = assembler
   }

   // MARK: - Functions

   /// Function loading all assemblies (starts on start application)
   func setup() {
       let assemblies = getAssemblies()
       assembler.apply(assemblies: assemblies)
   }

   /// All Assemblies of core dependencies
   private func getAssemblies() -> [Assembly] {
       return [
           AnalyticsAssembly(),
           ServiceComponentsAssembly(),
           ViewComponentsAssembly()
       ]
		/// Dependencies with other core dependencies
           + MyModuleDI(parentAssembler: assembler).assemblies
           + MonitoringAssembler(parentAssembler: assembler).assemblies
				
   }
}

Теперь в основном модуле все core-зависимости.

Создаем дочерний контейнер, куда передаем родительский. У Swinject доступно создание иерархии контейнеров. В конструкторе есть параметр для передачи родительского контейнера.

/// Child dependency
public final class MyModuleDI {
   // Child assembler
   private var assembler: Assembler

   // MARK: - Constructor
   public init(
       parentAssembler: Assembler
   ) {
       assembler = Assembler(
           [
               FooAssembly(),
               SomeComponentAssembly()
           ],
           parent: parentAssembler
       )
   }
}

Теперь у нас в дочернем Assembly доступны все зависимости родительского контейнера, импортированные в модуль.

import Monitoring
import Swinject

/// Some assembly for child dependency
class SomeComponentAssembly: Assembly {

    public func assemble(container: Container) {
       container.register(SomeProtocol.self) { res in
            // Dependency from other module                                  
            let logger = res.resolve(Logger.self)!
            return SomeComponent(logger)
        }.inObjectScope(.transient)
    }
}

UDF и DI

Наш проект реализован на архитектуре UDF, о которой можно прочитать в статьях моего коллеги Антона Гончарова (раз, два, три, четыре). Напомню основные термины, а затем посмотрим, как работать с ней и DI-контейнерами.

Reducer — чистая функция(State, Action) -> State

Store — хранилище состояния. Основано на паттерне Observer (вроде горячих сигналов в RAC). C одной поправкой — нельзя менять состояние внутри, кроме как отправитьAction. Тогда стейт изменится редьюсерами, которые эти экшены обрабатывают, и после всем подписчикам придет новое состояние.

Connector — чистая функция (State) -> Props

Component — все экраны, сервисы и прочие подписчики store.

Зоны ответственности 

В момент старта приложения или модуля, корневые компоненты должны подключиться к store для корректной функциональности. Основной assembler приложения или модуля отвечает за создание корневого экрана модуля и подключение к store сервисных компонентов.

public final class MyModuleDI {
    // DI Container
    private let assembler: Assembler
    // UDF store
    private let store: Store<MyModuleState>
    // Navigation coordinator
    private var router: StrongRouter<MyRootRoute>

    public init(store: Store<MyVerticalModuleState>, parentAssembler: Assembler) {
        assembler = Assembler([MyServiceComponentsAsembly()], parent: parentAssembler)
        self.store = store
        router = MyVerticalCoordinatorFactory(store: store).makeRootCoordinator().strongRouter
        connectComponents(to: store)
    }

    public func rootScreen(modulePayload: ICDeeplink) -> UIViewController {
        return router.viewController
    }

    private func connectComponents(to store: Store<MyModuleState>) {
        let serviceComponent = assembler.resolver.resolve(MyServiceComponent.self)
        serviceComponent?.connect(to: store)
        ...
    }
}

Это относится как к корневому, так и к дочернему DI-assembler. В них подключаются компоненты к store. Жизненный цикл Service Component привязан к жизненному циклу модуля и приложения.

View Components

За создание и подключение UI-компонентов к стору отвечает SceneFactory — протокол фабрики для создания View Component.

При создании View Component’a нам требуется подключить его к store. Жизненный цикл View Component привязан к координатору. Приведу пример подключения к модулю:

extension MyVerticalSceneFactory: MySceneFactory {
    func makeMyScene() -> UIViewController {
        let scene = MyViewController()
        scene.connect(to: store)
        return scene
    }
}

View Component'ы подключаются к store через фабрики координаторов.

extension MyVerticalCoordinatorFactory: MyCoordinatorFactory {
    func makeMyCoordinator() -> MyCoordinatorFactory {
        let coordinator = MyCoordinator(
            rootViewController: rootViewController,
            sceneFactory: sceneFactory,
            coordinatorFactory: self
        )
        coordinator.connect(to: store) { $0.myState.navigationStatus }
        return coordinator
    }
}

Почему View Component не нуждается в DI-контейнере? Есть несколько причин:

1. В UDF View Component конфигурируется через Props (аналог ViewModel), все необходимые параметры получаются через State и не имеют внешних зависимостей. Поэтому нецелесообразно класть его в DI.

2. Если в координаторе использовать только получение зависимостей, зона ответственности подключения к store переходит в координатор. И там придется использовать методы создания и подключения View Component.

3. View Component'ы, как и любые другие, убираются в DI-контейнер. Вопросы начинаются в store — каждый компонент должен быть подписан на него. Чтобы сделать это во время регистрации store должен быть в DI-контейнере.

Заключение

В конце приведу небольшие чекпоинты для модуляризации DI-контейнеров в проекте:

• Для использования DI-контейнера в модульном проекте необходима поддержка иерархии со стороны DI-контейнера.

• Обращайте внимание на масштаб проекта и метрики DI-контейнеров

• В UDF DI начинает забирать больше ответственности в связи с подключением к store.

На этом все. Спасибо, что читали. Задавайте ваши вопросы в комментариях.