仓储模式是解耦业务逻辑与数据访问的设计模式，通过统一接口封装CRUD操作，隔离数据库变更影响，支持测试与维护，可与ORM协作而非替代，适用于复杂业务或多数据源场景。
php 仓储模式（Repository Pattern）不是直接操作数据库的工具，而是一种解耦业务逻辑与数据访问细节的设计模式。它把“怎么查、怎么存、怎么删”这些数据库相关操作封装成统一接口，让上层代码只关心“我要什么数据”，而不是“用 pdo 还是 mysqli，表名是什么，SQL 怎么写”。
仓储模式的核心作用：隔离变化
当项目从 MySQL 换成 postgresql，或从原生 SQL 切到 Eloquent，甚至引入缓存层时，只要仓储接口不变，业务代码（比如 Controller 或 Service）完全不用改。这种隔离让维护和测试更轻松。
- 仓储类通常不直接写 SQL，而是调用 DAO（Data access Object）或 ORM 实例（如 PDO、Eloquent、Doctrine）
- 每个实体（如 User、Post）对应一个仓储类（UserRepository、PostRepository）
- 接口定义常见方法：find($id)、findAll()、findBy($conditions)、save($entity)、delete($entity)
一个轻量级 UserRepository 示例（基于 PDO）
不依赖框架，用原生 PHP 展示核心思路：
class UserRepository { private $pdo; <pre class="brush:php;toolbar:false;">public function __construct(PDO $pdo) { $this->pdo = $pdo; } public function find(int $id): ?User { $stmt = $this->pdo->prepare('SELECT * FROM users WHERE id = ?'); $stmt->execute([$id]); $row = $stmt->fetch(PDO::FETCH_ASSOC); return $row ? new User($row['id'], $row['name'], $row['email']) : null; } public function save(User $user): void { if ($user->getId()) { $stmt = $this->pdo->prepare('UPDATE users SET name = ?, email = ? WHERE id = ?'); $stmt->execute([$user->getName(), $user->getEmail(), $user->getId()]); } else { $stmt = $this->pdo->prepare('INSERT INTO users (name, email) VALUES (?, ?)'); $stmt->execute([$user->getName(), $user->getEmail()]); $user->setId((int) $this->pdo->lastInsertId()); } }}
立即学习“PHP免费学习笔记（深入）”；
注意：这里 User 是一个简单的领域实体（POPO），不含数据库逻辑；所有 SQL 细节被封在 UserRepository 内部。
和 ORM 的关系：不是替代，而是协作
很多人误以为用了 laravel Eloquent 就不需要仓储了。其实不然：
- Eloquent 是数据访问工具，关注“如何映射对象到表”
- 仓储是业务抽象层，关注“如何获取/持久化领域概念”
- 你可以让 UserRepository 内部使用 Eloquent Model，但对外只暴露 find/save 等语义化方法，隐藏 Model::where()、$model->save() 等实现细节
- 这样测试时可轻松 Mock 仓储，而不必启动数据库或绕过 Eloquent 的生命周期
什么时候值得引入？别为模式而模式
小项目或原型阶段，直接用 PDO 或 Eloquent 往往更高效。仓储模式的价值在以下场景才明显：
- 业务规则复杂，需要统一的数据获取策略（如自动过滤软删除、租户隔离、读写分离路由）
- 团队分工明确：后端工程师专注领域逻辑，dba 负责优化仓储内的查询
- 需对接多种数据源（MySQL + redis + 第三方 API），通过同一接口聚合结果
- 正在实践 DDD（领域驱动设计），仓储是核心构件之一
不复杂但容易忽略：仓储不是银弹，它的价值取决于你是否真需要那层抽象，而不是因为“别人说好”。