Firebase实时数据库---嵌套singleValueEventListeners是否不好?

时间:2019-03-10 19:57:38

标签: android firebase firebase-realtime-database

实时,您不能跨多个根节点执行单个查询,因此我想知道执行多个查询(一个接一个地嵌套)是否是一种不好的做法?我知道可以在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
                   }

          }


    }

2 个答案:

答案 0 :(得分:2)

从一般意义上讲,嵌套回调被认为是不良的编程风格。随意地说,它称为callback hell。随着您对这些回调的深入了解,代码变得越来越难以阅读和管理。

也就是说,如果它适合您,那就去吧。您是代码的老板。如果对您不起作用,则可以进行搜索以找到避免这种情况的策略。

答案 1 :(得分:1)

进行多次调用以从每个引用中读取相应条目的替代方法是复制每个引用下其他条目的数据。

在您的抽象示例中很难推理,所以让我们选择一个更具体,更简单的用例:一个聊天应用程序。假设您有两个级别的实体:用户和聊天消息。每个聊天消息由用户编写,并且用户具有显示名称。在最标准化的数据模型中,可能是:

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 pipelines the requests over a single connection起非常有效。

您可以使用缓存重复查找名称,因为用户名的更改频率通常比聊天消息的更改频率低得多。这减少了开销,因为您只加载了每个用户的数据一次,但是代码可能有点冗长。

另一种方法是复制用例所需的最少数据。这意味着您的数据模型将如下所示:

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条消息的列表。代价是您使用了更多的存储,但是通常应该认为存储便宜。代码的缺点是您现在需要写入重复的数据,这更加复杂。当然,重复的数据可能会不同步。

以上所有方法均有效。您选择哪种选择取决于应用程序的用例,复制数据时的舒适度以及您个人对代码量,带宽消耗等东西的重视程度。没有一个万能的答案,因此您必须自己拨打电话。

要对该主题进行一些很好的阅读/查看,请参见: