MVVM架构下：应为每个Activity单独建Repository还是用全局类？

这其实是MVVM架构落地时非常常见的困惑，我来分享下业内普遍认可的最佳实践，帮你平衡代码结构和可维护性：

不要为每个Activity单独创建Repository #

如果给每个Activity都单独写一个Repository，会导致大量重复代码——比如多个页面都需要操作新闻数据的话，每个Repository都要写一遍本地缓存判断、远程请求逻辑，不仅冗余，后期修改逻辑（比如缓存策略调整）时还要改N个地方，维护成本极高。而且Activity和Repository绑定过紧，违背了数据层和UI层解耦的初衷。

也不要做一个“大一统”的通用Repository #

一个包揽所有业务的超大Repository会变成所谓的“上帝类”，职责模糊，代码量动辄上千行，找个方法都要翻半天，后期扩展新业务时只会越来越臃肿，完全不符合单一职责原则，测试和维护都会变成噩梦。

推荐方案：按业务领域拆分Repository #

正确的姿势是围绕业务领域来划分Repository，每个Repository只负责一个特定业务模块的数据源操作：

• 比如你的新闻业务，就创建一个NewsRepository，专门处理新闻相关的本地缓存、远程请求逻辑；
• 如果后续有用户相关功能，就再创建UserRepository，负责用户信息、登录注册等数据操作；
• 以此类推，每个Repository只聚焦一个业务领域。

结合你的场景具体来说：

1. NewsRepository里实现getNews()方法，内部处理「检查本地缓存→有缓存返回本地数据→无缓存则调用远程接口→将返回数据存入本地缓存→返回数据」的完整逻辑；
2. 新闻相关的Activity对应的NewsViewModel，只需要依赖NewsRepository，调用它的getNews()方法即可；
3. 如果其他页面也需要获取新闻数据，直接复用NewsRepository就行，不用重复写逻辑。

进阶优化：Repository内部再拆分数据源 #

如果单个业务领域的逻辑比较复杂（比如新闻还有分类、搜索、收藏等），可以在Repository内部进一步拆分数据源：

• 比如创建NewsRemoteDataSource专门处理远程API请求；
• 创建NewsLocalDataSource专门处理本地数据库/SharedPreferences操作；
• NewsRepository作为中间层，协调这两个数据源的交互，自己只负责业务逻辑的编排，这样每个类的职责更单一，代码也不会臃肿。

这种拆分方式既保证了代码复用，又避免了单一类过于庞大，完全符合MVVM架构中数据层的设计原则，也是目前业内最常用的实践方式。

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