Использование синглтона для Bloc

Я знаю, что некоторые из моих BLOC будут созданы только один раз на протяжении жизненного цикла приложения. Это плохая практика или анти-шаблон - создавать эти классы BLOC как одноэлементные. Синглтон может помочь в доступе к BLOC где угодно, а также гарантирует, что класс создается только один раз.

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

Каковы могут быть последствия этого?

Редактировать

У меня два блока

  1. AuthenTicationBloc - это глобальный блок
  2. UserBloc - должен существовать только один раз (синглтон)

AuthenTicationBloc должен использовать UserBloc внутри себя. Если бы я сделал UserBloc синглтоном, можно было бы просто использовать его как UserBloc().

В противном случае мне пришлось создать UserBloc как переменную экземпляра в AuthenTicationBloc следующим образом:

class AuthenTicationBloc {
  UserBloc _userBloc;

  AuthenTicationBloc({@required UserBloc userBloc}) : _userBloc = userBloc;


  myMethod(){
    //use the userBloc
    _userBloc.setDetails();
  }
}


runApp(
  UserBloc userBloc = UserBloc();

  Provider(
    value: AuthenTicationBloc(userBloc: userBloc),
    child: MyApp(),
  ),
);

Если бы мне пришлось использовать UserBloc в цепочке виджетов где-то еще, мне пришлось бы сделать так, чтобы UserBloc также предоставлялся глобально, как показано ниже, верно?

UserBloc userBloc = UserBloc();

MultiProvider(
  providers: [
    Provider<AuthenTicationBloc>(
      value: AuthenTicationBloc(userBloc:userBloc),
    ),
    Provider<UserBloc>(
      value: userBloc,
    ),
  ],
  child: MyApp(),
);

person Vamsi Krishna    schedule 10.03.2019    source источник


Ответы (1)


Поведение остается прежним. Синглтон против InheritedWidget не сильно меняет

Но это имеет несколько архитектурных последствий, поскольку вы должны использовать InheritedWidget для BLoC, которые не «создаются только один раз на протяжении жизненного цикла приложения».

Что обозначает:

  • вы будете смешивать InheriedWidgets и Singletons в своем приложении. Уменьшение согласованности, поскольку у вас есть два разных способа создания / использования BLoC
  • когда спецификации меняются, становится труднее адаптироваться. Вполне возможно, что в будущем вам, возможно, придется создавать его более одного раза. Это означает, что вам придется редактировать все приложение

С другой стороны, синглтоны не предотвращают некоторые ошибки, которые делают InheritedWidgets.

Например, невозможно иметь циклическую зависимость с помощью InheritedWidgets, когда это определенно возможно с помощью синглтонов.


Вы не выиграете много, используя Singleton vs InheritedWidget с точки зрения кода.

В Pub есть много библиотек, которые упростят вашу работу. Включая провайдера:

runApp(
  Provider(
    value: MyBloc(),
    child: MyApp(),
  ),
);
person Rémi Rousselet    schedule 12.03.2019
comment
Спасибо за объяснение. Круговая зависимость может стать проблемой. Мой случай использования синглтона больше связан с его использованием в другом блоке, а не с созданием его как свойства .. См. Мое изменение вопроса. - person Vamsi Krishna; 13.03.2019
comment
Тот факт, что InheritedWidgets требует передачи BLoC в качестве параметра вместо прямого использования переменной, является причиной предотвращения циклической зависимости. - person Rémi Rousselet; 13.03.2019
comment
Да нормально! - person Rémi Rousselet; 13.03.2019