- Таким образом, поток данных в архитектуре RIB в основном сверху вниз.Значит ли это, что весь поток данных, который нужен дочерним RIB, должен быть подготовлен / готов заранее в корневых RIB?Если да, что означает, что все API-интерфейсы / сетевые вызовы / операции с базой данных выполняются внутри корневых RIB?
- Если корневые RIB хранят все состояние приложения, все эти потоки инициализируются во время загрузки?Могу я лениво инициализировать часть из них, так как некоторые из них не требуются, если этот конкретный дочерний RIB еще не присоединен к дереву?
- Ссылаясь на эту статью из инженерного блога Uber https://eng.uber.com/deep-scope-hierarchies/
Новое приложение Rider: Deep Scope Hierarchy
Учитывая, что у двух- и трехуровневых иерархий областей видимости есть серьезные проблемы, мы не ограничивались заданным количеством слоев областей действия при разработке новогоприложение.Вместо этого мы создали новые промежуточные слои области видимости, где бы они ни были полезны.Например, область PreRequest используется для хранения объектов, которые должны совместно использоваться всеми состояниями экрана PreRequest, такими как Home, ProductSelection и RefinementSteps.
Существуют ли какие-либо критерии, какой тип объекта / состоянияили когда мы должны использовать подход intermediary scope layers, но не создавать поток DI в Root и подавать дочерние ребра в качестве зависимости?
Что нас должно беспокоить?Требует ли это вызова API?Не связанные с бизнес-логикой состояния, например логика пользовательского интерфейса?
Случай использования, который мне приходит в голову, - это, возможно, раздел регистрации приложения.
Возможно, нам потребуется создать intermediary scope layer длясохранить информацию, которую заполнил пользователь (до тех пор, пока пользователь не нажмет кнопку регистрации / завершения).Если пользователь нажимает кнопку регистрации, пользовательский объект будет отправлен обратно в родительские RIB через прослушиватель?Правильный?