模块化架构下 Room 数据库的使用设计

背景

Android 模块化架构盛行已久，在模块中使用数据库也是常有的需求；而我们都知道，Android 提供了 Room 数据库架构组件来大大提升我们写数据库的便利性。

那么，大家在模块化架构下，room 数据库是如何使用的呢？

我们围绕一个场景来讲，比如一个新闻类的应用，里面有壳 App（appModule）、用户账号模块（AccountModule）、新闻模块（NewsModule）；其中账号模块和新闻模块需要用到数据库；

常用做法及优缺点；

用法可能也比较多，我在这里列举两种比较常见的方式；

1、DBModule 方案

做法：大乱炖方式，将整个项目所有的 Model、DAO 还有 database 的初始化和单例对象都放在此 module；其他需要用到数据库的 module 依赖此 module；如下图所示：

优点：

开销小：全局只有一个数据库单例；
写法简单：只要用到数据库的 module，依赖 DBModule，再把 model 和 DAO 往里一丢就完事；

缺点：

耦合高：不符合开闭原则，对 DBModule 的每次修改都有可能影响到依赖此 module 的功能；
代码边界模糊：多个模块的数据和业务逻辑都糅合在同个 module；
复用性低：多模块还有个作用，就是模块可以给多个应用复用，但是数据库相关逻辑都在同个 module，显然不好迁移；

2、多数据库方案

做法：各立山头方式，每个用到 DB 的子 module 都自己维护一个数据库；自己继承 RoomDatabase 去单独实现一个数据库；如下图：

优点：

无耦合、代码边界独立、复用性高；

缺点：

开销大：Room 的官方文档中提示了，每个 database 的实例都是「非常昂贵」的；因此多模块都有 DB 的情况下，可能存在较大的资源开销问题；

我思考的方案

我们先把遇到的问题点或者说期望做到的点梳理一下：

低耦合、模块容易迁移；
代码边界清晰，每个模块只管自己的 Model 和 DAO；
尽可能小的开销：单例；

直接说方案：Database 单例放在主 module 中；各个子 module 维护自己的 Model 和 DAO； 由于主 module 也会依赖其他子 module，因此 Database 声明的时候是可以拿到各个子 module 的 Model 和 DAO；

那现在要解决的就是子 module DAO 的实例化问题了，Room 中 DAO 的实例化方式是通过 DataBase 的实例去获取的，因此，可以在子 module 需要用到 DAO 的时候向主 module 索取即可；

大概关系图如下：

但是，从上图可以看出，AccountModule 和 NewsModule 中指向 App 的两条虚线这个依赖方向显然有问题；我们只能是壳 app 依赖子 module，不能反过来；

所以现在有个依赖方向要解决，子 module 不能依赖主 module，直接方式拿不到 DB 实例的，因此可以暴露一个接口出去，在主 module 中去实现这个接口，返回对应 DAO 的实例即可；

子 module 中：

AccountModule 的访问层 AccountRoomAccessor，定义了一个接口；NewsModule 类似；

object AccountModuleRoomAccessor {
  var onGetDaoCallback: OnGetDaoCallback? = null

  internal fun getUserDao(): UserDao {
    if (onGetDaoCallback == null) {
    throw IllegalArgumentException("onGetDaoCallback must not be null!!")
    }
    return onGetDaoCallback!!.onGetUserDao()
  }

  interface OnGetDaoCallback {
    fun onGetUserDao(): UserDao
  }
}

壳 App 中：

数据库初始化，声明子 module 的 DAO 和 model：

@Database(
    entities = [
        UserModel::class,
        NewsDetailModel::class,
        NewsSummaryModel::class
    ],
    version = 1,
    exportSchema = false
)
abstract class TestDataBase : RoomDatabase() {
    abstract fun userDao(): UserDao
    abstract fun newsSummaryDao(): NewsSummaryDAO
    abstract fun newsDetailDao(): NewsDetailDAO
}

实现子 module 接口此接口，并将 DAO 实例返回：

class App: Application() {

    ... ...

    override fun onCreate() {
        super.onCreate()
        ... ...

        AccountModuleRoomAccessor.onGetDaoCallback = object : AccountModuleRoomAccessor.OnGetDaoCallback {
            override fun onGetUserDao(): UserDao {
                return DBHelper.db.userDao()
            }
        }

        NewsModuleRoomAccessor.onGetDaoCallback = object : NewsModuleRoomAccessor.OnGetDaoCallback {
            override fun onGetNewsDetailDAO(): NewsDetailDAO {
                return DBHelper.db.newsDetailDao()
            }
            override fun onGetNewsSummaryDAO(): NewsSummaryDAO {
                return DBHelper.db.newsSummaryDao()
            }
        }
    }
}

这样就可以解决上面几个问题了；

当 module 需要迁移的时候，虽然没有方案 B 来得快，但是 Model 和 DAO 都不需要手动拷贝，只需要注册到另外一个 App 的 Database 即可；

但....还有个问题，对于实现者来说，每个 module 都需要自己定义一个访问层，暴露一个接口，再去实现实在有点繁琐。。。

所以，是否可以用自动生成代码的方式来做这一层。答案当然是可以的。

我写了一个基于 APT 的代码生成库，会自动遍历每个 module 里面的 @DAO 注解，然后自动生成访问层；没错，上面 AccountModuleRoomAccessor 就是自动生成的；

代码可见：github.com/linkaipeng/…

实例可见仓库里面的 demo

至此，就是我思考的这个方案的全部了。

另外，还有些不足吧

这种方案虽然可以比较好将每个 module 数据库相关的代码放在每个 module 中；但是壳 App 依赖子 module 的方式还是得通过 implementation 去依赖（因为数据库声明需要 import 到 DAO 和 model）；

但是最理想的依赖方式应该是通过 runtimeOnly；这个也探索过一些做法，比如增加一层纯粹的数据库中间层（module 方式存在），壳 App 通过 runtimeOnly 依赖此中间层，中间层再通过 implementation 去依赖有数据库需求的子 module；这样可以将壳 App 彻底和子 module 隔离开，避免壳 App 中可以访问到子 module；

或者还有其他更赞的方案，可以来一起探讨。