Right DI implementation for Flutter

[artem-zaitsev]

Ru description:

Бизнесовые зависимости (репозитории, клиенты) при использовании стейтменеджеров могут использоваться всего в 2ух вариантах:

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

2. Provider/InheritedWidget, в общем контекст флаттера для доставки зависимостей. Да, тут уже будет жизненный цикл, область видимости и зависимости, но при этом репозитории будут находится в presentation слое и будут привязаны к UI фреймворку. В общем это противоречит чистой архитектуре.

Нужен некоторый подход с отделением зависимостей от контекста, но с сохранением возможности выделять скоупы и ЖЦ.

En comming soon.

[PlugFox]

Да, нужно придумать некий рецепт, берущий лучшее от двух миров.
Тоесть между стейт менеджером и ui нужно выделить еще 1 слой.

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

Причем в идеале при изменении зависимости нужно и пересоздавать зависимое от нее.
Пример: Изменился пользователь, нужно пересоздать на основании этого провайдеры и DAO базы данных для реализации RLS.
Таким образом мы технически никогда не сможем допустить ситуации, что пользователь получит не свой кэш или получит из бд данные другого пользователя. А также не придется с каждым запросом передавать идентификатор этого пользователя.

class VehicleRepositoryImpl implements VehicleRepository {
  final CollectionReference _collection;
  VehicleRepositoryImpl({@required FirebaseFirestore firestore, @required User user})
      : _collection = firestore.collection('users').doc(user.uid).collection('vehicles');

  // В данном примере, любой метод репозитория [VehicleRepository]
  // взаимодействующий с [CollectionReference] будет иметь доступ
  // только к данным текущего пользователя [User]
}

Естественно это касается не только пользователя, а вообще каждой зависимости и зависимости зависимости и зависимости зависимости от зависимости. Таким образом мы реактивно все связываем и при изменении А меняется B в свою очередь изменяя C которое зависит от B. Это как клеточки Excel.

Сейчас смотрю в сторону
https://pub.dev/packages/koin

Modules
Scopes
Singleton provider(definition)
Factory provider(definition)
Scoped provider(definition)
Support to multiple bindings
Support to named provider(definition)
Easy testing
Lazy inject
Logging
Support to parameter injection
Integration by default for Bloc library
DevTools for state inspection

Как я понял, он на 95% перенесен из Kotlin и сейчас страдает только из за недостатка комьюнити дарта и наличия примеров.

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