多模块项目中结合Dagger 2使用Room Database的方案咨询

你的Clean架构按功能划分包的结构没问题，core层负责通用基础能力，各个feature模块独立封装业务逻辑，完全符合模块化设计的思路。

针对你问的问题：完全可以把feature模块里的DAO注入或注册到core层的AppDatabase中，这也是解决这类循环依赖的常用方案，给你几个可行的实现方式：

1. 动态注册DAO（推荐，贴合你现有结构） #

Room本身支持动态获取DAO实例，不用在core层的AppDatabase里提前声明所有DAO：

• core层的AppDatabase只负责定义数据库基础配置和实体类，不写任何DAO声明：

@Database(entities = [ProjectEntity::class, PartEntity::class, CounterEntity::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    // 这里空着，不声明DAO
}

• 每个feature模块里正常写自己的DAO，比如feature/addproject/data/local/database/dao/ProjectDao.kt：

@Dao
interface ProjectDao {
    @Insert
    suspend fun insertProject(project: ProjectEntity)

    @Query("SELECT * FROM project")
    suspend fun getAllProjects(): List<ProjectEntity>
}

• 然后在feature模块的DI配置里，直接从AppDatabase获取DAO实例注入：

@Module
@InstallIn(SingletonComponent::class)
object AddProjectModule {
    @Provides
    fun provideProjectDao(appDatabase: AppDatabase): ProjectDao {
        return appDatabase.getDao(ProjectDao::class.java)
    }
}

Room会自动处理DAO的实例化，只要对应的实体已经在AppDatabase里声明过就行，这样core层不用依赖feature模块，feature模块只依赖core层的AppDatabase，完美解决循环依赖。

2. 用接口抽象解耦（更符合Clean架构依赖倒置） #

要是不想靠Room的动态获取能力，也可以用依赖倒置原则：

• 在core层定义DAO的抽象接口，比如core/data/local/database/dao/BaseProjectDao
• 在feature模块里实现这个接口，并用Room的@Dao注解标记具体实现
• 最后通过DI把feature层的实现类注入到业务逻辑里

这种方式让core层只依赖抽象，feature层负责具体实现，彻底切断循环依赖的可能，不过需要多写一层抽象接口，适合对架构严谨性要求更高的场景。

3. 拆分独立数据库（可选） #

如果各个feature模块的业务完全隔离，实体没有关联，也可以给每个feature单独建一个Room数据库，但这种方式会增加数据库的管理成本，比如备份、迁移都要分开处理，一般只适合业务完全独立的场景。

总结下，第一种动态注册DAO的方式最适合你的现有项目结构，既能保持feature模块的独立性，又能解决循环依赖的问题，配合DI框架用起来也很顺畅。

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