基于Java的Android Firebase实时数据库CRUD开发，能否为每个模型类配独立RecyclerView

完全可以在项目里使用多个RecyclerView，给Company、Local、Employee每类模型单独配一个RecyclerView没有任何技术问题，是完全可运行的实现。
这种方式对新手开发非常友好：

• 逻辑拆分清晰：每个RecyclerView绑定独立的Adapter、独立的列表item布局，和对应的数据类型一一对应，写代码时不需要考虑多类型兼容问题，调试时出bug也很容易定位
• 稳定性高：只要你的页面结构是单页展示一类数据，单RV的结构完全不会出现嵌套滑动、布局错位这类新手常踩的坑

如果觉得维护多套Adapter、多RV的工作量太大，可以根据你的实际UI交互选下面的方案，不需要硬套多RV的实现：

1. 多Fragment+单RV的轻量结构 #

这也是你做CRUD项目最省事的结构：

• 配合你已经引入的Material库的BottomNavigationView，把三个列表分别放到三个独立的Fragment里
• 每个Fragment内部只放一个对应类型的RecyclerView，直接绑定自己的Firebase实时数据库监听、自己的列表Adapter
• 这种结构和单独做三个Activity展示列表相比，内存占用更低，交互也更符合用户习惯

2. 单RV多视图类型的混排方案 #

如果你的需求是在同一个滚动页面里混合展示三种不同类型的数据，就没必要嵌套三个RecyclerView了：

• 只需要用一个RecyclerView，在对应的Adapter里重写getItemViewType()方法，给Company、Local、Employee三类数据设置不同的视图类型标识
• 在创建ViewHolder的时候根据类型加载对应的item布局，绑定对应的字段即可
• 这种方式比多层嵌套RV的性能好很多，也不会出现嵌套滑动时列表卡顿的问题

• 你当前的build.gradle里对firebase-database做了重复引入：已经通过firebase-bom:26.1.0统一管理版本的前提下，后面单独声明的implementation 'com.google.firebase:firebase-database:19.6.0'是冗余配置，删掉即可，避免出现版本不一致的依赖冲突
• 做Firebase实时数据库的反序列化时，所有模型类必须保留公开的无参构造函数：你现在写的Company、Local都符合要求，后续写Employee类的时候也一定要加上这个无参构造，否则读取数据时会直接抛出反序列化异常
• 模型类里的key字段不要手动通过构造函数传值：读取数据库快照的时候直接从DataSnapshot里取对应的键赋值给模型的key字段即可，手动传值很容易出现key不匹配，导致后续更新、删除操作定位不到对应数据的问题

内容的提问来源于stack exchange，提问作者Nuno Meira