PHP 中的 Repository 不等于“设计模式”本身，而是对“仓储模式（Repository Pattern）”这一经典设计模式的具体实现。
关键在于：Repository 是一种架构约束，用于解耦业务逻辑与数据访问，而非单纯代码组织技巧。
一、本质定义：仓储模式（Repository Pattern）
- 起源：Martin Fowler《企业应用架构模式》
- 核心思想：
“用集合式接口抽象数据访问，使领域层无需关心数据来源（DB/Cache/API）”
- 目的：
- 解耦业务逻辑与持久化机制
- 提供内存集合般的操作体验（
$users->findById(1)） - 便于单元测试（Mock Repository 而非真实 DB）
✅不是 CRUD 封装！
若 Repository 只是User::where(...)->get()的代理，则沦为贫血模型，失去模式价值。
二、PHP 中的典型实现（以 Laravel 为例）
1.错误示范：伪 Repository
// UserRepository.phpclassUserRepository{publicfunctionfind($id){returnUser::find($id);// 直接调用 Eloquent}}- 问题：
- 业务层仍依赖 Eloquent（
User模型） - 无法切换数据源（如从 MySQL 到 MongoDB）
- 测试时仍需数据库
- 业务层仍依赖 Eloquent（
2.正确实现：契约隔离
// 定义接口（解耦关键）interfaceUserRepositoryInterface{publicfunctionfindById(int$id):?UserEntity;publicfunctionsave(UserEntity$user):void;}// Eloquent 实现classEloquentUserRepositoryimplementsUserRepositoryInterface{publicfunctionfindById(int$id):?UserEntity{$model=User::find($id);return$model?$this->toEntity($model):null;}privatefunctiontoEntity(User$model):UserEntity{returnnewUserEntity($model->id,$model->name,...);}}// 领域实体（纯 PHP 对象，无框架依赖）classUserEntity{publicfunction__construct(publicreadonlyint$id,publicreadonlystring$name){}}3.业务层使用
// UserService.phpclassUserService{publicfunction__construct(privateUserRepositoryInterface$users){}publicfunctionpromoteUser(int$id){$user=$this->users->findById($id);if(!$user)thrownewUserNotFound();// 业务逻辑（与框架无关）$user->role='admin';$this->users->save($user);}}三、Repository 的核心价值
| 维度 | 价值 |
|---|---|
| 可测试性 | MockUserRepositoryInterface，无需数据库 |
| 可替换性 | 切换数据源只需新实现（如RedisUserRepository） |
| 领域纯净 | 业务逻辑不污染 ORM 方法（如->where()->first()） |
| 聚合根支持 | 复杂聚合（如 Order + Items）通过单一入口管理 |
⚠️Laravel 的陷阱：
Eloquent 模型既是Active Record又是领域对象，天然阻碍 Repository 模式落地。
必须引入 DTO/Entity 分离。
四、何时需要 Repository？
| 场景 | 建议 |
|---|---|
| 简单 CRUD 应用 | ❌ 不需要（过度设计） |
| 复杂业务逻辑 | ✅ 必须（解耦领域与基础设施） |
| 多数据源 | ✅ 必须（统一访问接口） |
| 严格单元测试 | ✅ 必须（避免测试依赖 DB） |
💡经验法则：
当你的业务逻辑需要独立于框架演进时，Repository 才有价值。
五、常见误区
| 误区 | 正确理解 |
|---|---|
| “Repository = DAO” | DAO 封装 SQL，Repository 封装聚合行为 |
| “所有 Model 都要 Repository” | 仅聚合根（Aggregate Root）需要 |
| “用 Repository 就是 DDD” | Repository 只是 DDD 的战术模式之一 |
| “Laravel Service Provider 自动绑定就是 Repository” | 绑定的是实现，接口隔离才是核心 |
六、替代方案：现代 PHP 的简化实践
- Action-Domain-Responder (ADR)
- 用 Domain Service 替代 Repository
- CQRS
- Query 用简单 DB facade，Command 用领域模型
- 纯函数式数据访问
// users.phpfunctionfind_user_by_id(int$id):?array{returnDB::table('users')->where('id',$id)->first();}
✅务实建议：
小型项目用 Eloquent 直接查，中大型项目在核心域引入 Repository。
总结
- Repository 是设计模式，但PHP 中的实现常被简化为 CRUD 封装，失去其解耦本质。
- 核心标志：
- 存在接口（Interface）
- 返回纯领域对象（非 Eloquent Model）
- 业务层零 ORM 依赖
- 工程原则：
不要为了模式而模式，而要为“未来可演进性”而模式。
