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

最新推荐文章于 2024-09-25 11:06:23 发布

2401_84123584

最新推荐文章于 2024-09-25 11:06:23 发布

阅读量423

点赞数 4

分类专栏：程序员文章标签：数据库架构

本文链接：https://blog.csdn.net/2401_84123584/article/details/137458953

版权

程序员专栏收录该内容

178 篇文章 1 订阅

订阅专栏

代码边界清晰，每个模块只管自己的 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；
或者还有其他更赞的方案，可以来一起探讨

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。