在使用Room的Android应用中应创建多少个Repository？

这是个非常常见的Room架构设计疑问，咱们结合Android官方架构组件的最佳实践来逐个拆解下这几个方案的优劣：

方案1：单Repository管理所有DAO #

• 优点：初期实现简单，不用创建多个Repository类，所有数据操作入口统一。
• 缺点：随着应用功能迭代，这个Repository会变得越来越臃肿，同时处理N种实体的增删改查逻辑，违反单一职责原则，后期维护、测试都会非常麻烦，代码耦合度极高。

方案2：每个DAO对应一个Repository #

这是我最推荐的方案，符合架构分层的核心思想：

• 优点：每个Repository只负责对应实体（或一组强关联实体）的数据操作，职责单一。比如UserRepository只处理用户相关的本地数据逻辑，ArticleRepository专注于文章数据，代码模块化程度高，易维护、易测试，也方便后续扩展（比如给某个Repo添加网络请求+本地缓存的逻辑）。
• 补充：官方codelab里只用了一个Repository，是因为示例只有一个实体，场景简单。实际项目中，多实体场景下拆分Repo才是更合理的选择。

方案3：每个Activity对应一个Repository #

这个方案不太推荐：

• 问题：Activity属于UI层，它的需求可能会频繁变化，而且一个Activity往往需要操作多种实体的数据（比如首页可能同时展示用户信息、推荐列表），这会导致对应的Repository被迫处理多个DAO的逻辑，最终还是会变得臃肿，同时把数据层和UI层强耦合，违背了架构分层的初衷（数据层应该独立于UI层变化）。

其他补充方案 #

如果遇到需要跨多个实体的复杂业务逻辑（比如同时更新用户信息和订单状态），可以：

• 单独创建一个业务级Repository，依赖多个基础Repository来协调操作；
• 或者使用UseCase（用例）层来封装这类跨实体的业务逻辑，让Repository只专注于单一实体的数据操作。

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