База данных Firebase в реальном времени --- Являются ли вложенные singleValueEventListeners плохой практикой?

Question

В реальном времени вы не можете выполнить один запрос для нескольких корневых узлов, поэтому мне было интересно, является ли выполнение нескольких запросов (вложенных один за другим) плохой практикой? Я понимаю, что это можно сделать одним запросом в firestore, но я специально использую реальное время для этой части моего приложения из-за большого количества пользовательских операций чтения / записи.

reference.addListenerForSingleValueEvent(new ValueEventListener() {
    @Override
    public void onDataChange(@NonNull DataSnapshot dataSnapshot) {

          //get Data from query one here  

         reference2.addListenerForSingleValueEvent(){
            //get Data from query two here

                    reference3.addListenerForSingleValueEvent(){
                       //get Data from query three here
                   }

          }


    }

Answer 1

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

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

Answer 2

Альтернативой выполнению нескольких вызовов для считывания соответствующих записей из каждой ссылки является дублирование данных других записей под каждой ссылкой.

Немного сложно рассуждать в вашем абстрактном примере, поэтому давайте выберем более конкретный и простой пример использования: приложение для чата. Допустим, у вас есть двухуровневые объекты: пользователи и сообщения чата. Каждое сообщение в чате написано пользователем, и у пользователя есть отображаемое имя. В наиболее нормализованной модели данных это может быть:

users: {
  user1: {
    name: "david s."
  },
  user2: {
    name: "Doug Stevenson"
  },
  usere: {
    name: "Frank van Puffelen"
  }

},
messages: {
  message1: {
    message: "In real time you can't do a single query across multiple...",
    uid: "user1"
  },
  message2: {
    message: "In a very general sense, nested callbacks...",
    uid: "user2"
  }
  message1: {
    message: "The alternative to doing multiple calls...",
    uid: "user3"
  }
}

Теперь предположим, что у нас есть сценарий использования, в котором мы хотим отобразить последние 10 сообщений чата, каждое с именем пользователя, который отправил это сообщение.

Приведенные выше данные работают нормально, но вам нужно будет прочитать имена пользователей из узла /users, в значительной степени, как вы делаете сейчас. Это известно как клиентское соединение , и оно довольно эффективно, поскольку Firebase передает запросы по одному соединению .

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

Альтернативой является дублирование минимальных данных , которые вам нужны для вашего варианта использования. Это означает, что ваша модель данных будет выглядеть так:

users: {
  user1: {
    name: "david s."
  },
  user2: {
    name: "Doug Stevenson"
  },
  usere: {
    name: "Frank van Puffelen"
  }

},
messages: {
  message1: {
    message: "In real time you can't do a single query across multiple...",
    name: "david s.",
    uid: "user1"
  },
  message2: {
    message: "In a very general sense, nested callbacks...",
    name: "Doug Stevenson",
    uid: "user2"
  }
  message1: {
    message: "The alternative to doing multiple calls...",
    name: "Frank van Puffelen",
    uid: "user3"
  }
}

Теперь вы можете отобразить список последних 10 сообщений за одно чтение. Стоимость заключается в том, что вы используете больше хранилища, но обычно хранилище следует считать дешевым. Недостаток в коде заключается в том, что теперь вам нужно записывать дублирующиеся данные, что является более сложным. И, конечно, дублированные данные могут быть не синхронизированы.

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

Для отличного чтения / просмотра по теме см .:

• Моделирование данных NoSQL
• Firebase для разработчиков SQL
• Как записать денормализованные данные в Firebase
• Структура данных Firebase и URL
• еще немного моих ответов на вопросы по NoSQL