Swift实现Repository模式：选择值类型还是引用类型？

在项目中实现Repository模式时，我们常常会纠结：应该将仓库实现为class（引用类型）还是struct（值类型）？以下是两种方案的优缺点分析，帮助你建立对应的认知模型。

问题示例参考 #

假设我们定义了如下Repository协议：

protocol UserRepository {
    func get(id: Int) -> AnyPublisher<User, MyError>
}

我们可以选择用class实现：

class LocalUserRepository: UserRepository {
    func get(id: Int) -> AnyPublisher<User, MyError> {
        // 实现逻辑
    }
}

也可以选择用struct实现：

struct LocalUserRepository: UserRepository {
    func get(id: Int) -> AnyPublisher<User, MyError> {
        // 实现逻辑
    }
}

选择Class的优缺点 #

优势 #

• 更易管理外部资源：比如数据库连接、网络会话这类需要长期持有的资源，引用类型不会因为值拷贝导致资源重复创建，避免资源浪费或状态混乱
• 状态修改更简洁：修改仓库内部状态时，无需给方法标记mutating关键字，代码逻辑更直观
• 天然支持共享缓存：可以用字典等结构实现缓存，所有引用该实例的组件都会共享同一缓存状态，更新后能同步生效
• 支持继承：可以基于基础仓库类扩展出不同的变体，复用通用逻辑
• 适合依赖注入：在多个组件间共享同一仓库实例，避免重复初始化的开销

劣势 #

• 状态共享易引发副作用：一处修改会影响所有持有该实例引用的地方，调试时需要追踪所有引用点，排查问题难度更高
• 存在内存泄漏风险：需要手动注意循环引用问题，尤其是在闭包中引用实例时
• 多线程需额外处理线程安全：共享状态在多线程环境下容易出现数据竞争，需要加锁等机制保障安全

选择Struct的优缺点 #

优势 #

• 状态隔离，易推理：每个实例都是独立的值拷贝，不同实例间的状态完全隔离，不会出现意外的交叉影响，代码逻辑更易理解和测试
• 无内存泄漏顾虑：值类型的内存由系统自动管理，无需担心循环引用问题
• 多线程默认安全：每个线程操作的都是自己的实例拷贝，天然避免了数据竞争问题
• 语法轻量：初始化简单，不需要处理继承相关的复杂逻辑

劣势 #

• 状态修改繁琐：修改内部状态时必须给方法添加mutating关键字，代码冗余
• 不适合持有外部资源：值拷贝会导致资源被多次创建，可能引发资源耗尽或状态不一致
• 无法实现共享缓存：每个实例的缓存都是独立的，多个实例间无法同步缓存状态
• 不支持继承：无法通过继承复用代码，只能依赖协议扩展或组合来实现逻辑复用

总结 #

没有绝对的最优选择，需根据业务场景判断：

• 当仓库需要管理外部资源、实现共享缓存、支持继承，或需要在多个组件间共享同一状态时，优先选择class
• 当仓库逻辑简单、状态独立，更看重线程安全和易测试性时，优先选择struct

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