Repository模式通过抽象数据库操作，将数据访问逻辑与业务逻辑分离，提升代码可维护性和可测试性。在Laravel中，可通过创建Repository类封装Eloquent模型操作，并结合接口实现依赖注入。建议目录结构为app/Repositories及Contracts子目录，定义UserRepositoryInterface等接口并绑定至具体实现类。控制器中依赖接口而非具体模型，使代码更轻量且易于测试。应避免简单代理Eloquent方法，而需按业务场景封装如getActiveUsersWithPosts等高阶方法。复杂查询可引入Criteria模式动态组合条件，同时善用模型本地作用域保持语义清晰。并非所有模型都需Repository，仅在涉及多数据源、复杂逻辑或频繁变更时才值得使用。关键在于以接口解耦、按业务命名方法、合理复用Eloquent特性，避免过度封装。
在 Laravel 应用中使用 Repository 模式，主要是为了将数据访问逻辑从控制器中解耦，提升代码的可维护性、可测试性和可重用性。虽然 Laravel 自带强大的 Eloquent ORM，但直接在控制器中调用模型会使代码变得臃肿。通过引入 Repository 模式，可以更好地组织业务逻辑。
什么是 Repository 模式？
Repository 模式是一种设计模式，用于抽象数据库操作。它充当数据源（如数据库）与业务逻辑之间的中介，使得上层代码无需关心数据是如何获取或存储的。
在 Laravel 中，一个典型的 Repository 通常是一个类，封装了对某个 Eloquent 模型的所有操作，比如查询、创建、更新、删除等。
建立清晰的目录结构
良好的目录结构有助于团队协作和后期维护。建议将 Repository 放在 app/Repositories 目录下，并根据功能模块进行分组。
- app/Repositories/UserRepository.php
- app/Repositories/PostRepository.php
- app/Repositories/Contracts/UserRepositoryInterface.php
- app/Repositories/Contracts/PostRepositoryInterface.php
接口定义契约，具体实现类遵循该契约。这种做法便于后期替换实现或使用 Mock 进行单元测试。
定义接口并绑定服务容器
为每个 Repository 创建对应的接口，确保依赖注入时面向接口编程。
interface UserRepositoryInterface {
public function all();
public function find($id);
public function create(array $data);
public function update($id, array $data);
public function delete($id);
}
在 AppServiceProvider 或单独的服务提供者中绑定接口与实现：
$this->app->bind(
UserRepositoryInterface::class,
UserRepository::class
);
这样在控制器中就可以通过类型提示自动注入实现类。
在控制器中使用 Repository
控制器不再直接调用 Eloquent 模型，而是依赖 Repository 接口。
class UserController extends Controller
{
protected $userRepository;
public function __construct(UserRepositoryInterface $userRepository)
{
$this->userRepository = $userRepository;
}
public function index()
{
$users = $this->userRepository->all();
return response()->json($users);
}
}
这种方式让控制器更轻量，也更容易测试。你可以轻松地为 Repository 提供 Mock 实现来隔离数据库依赖。
避免过度封装 Eloquent 方法
一个常见的误区是把所有 Eloquent 方法都原样暴露在 Repository 中，例如写一堆 where()、orderBy() 等通用方法。这会导致 Repository 变成“代理壳”，失去意义。
正确的做法是根据业务场景封装有意义的方法。
// 好的做法：体现业务含义
public function getActiveUsersWithPosts()
{
return User::where('active', 1)->has('posts')->get();
}
// 避免这样做：只是转发查询构建器
public function where($column, $value)
{
return $this->model->where($column, $value);
}
Repository 应该提供“动词+名词”形式的高阶方法，反映真实业务需求。
结合 Criteria 或 Query Objects 处理复杂查询
当查询逻辑变得复杂时，可以在 Repository 中引入 Criteria 模式，动态添加查询条件。
例如：
interface CriterionInterface
{
public function apply(Builder $query): Builder;
}
class ActiveUsersCriterion implements CriterionInterface
{
public function apply(Builder $query): Builder
{
return $query->where('active', true);
}
}
// 在 Repository 中使用
public function withCriterion(CriterionInterface $criterion)
{
return $criterion->apply($this->model->newQuery());
}
这种方式可以让查询逻辑更加灵活且可组合。
善用 Laravel 的本地作用域（Local Scopes）
Repository 并不需要替代 Eloquent 的全部功能。对于通用的查询条件，推荐在模型中定义本地作用域，然后在 Repository 中调用。
// 在 User 模型中
public function scopeActive($query)
{
return $query->where('active', 1);
}
// 在 Repository 中使用
public function getActiveUsers()
{
return User::active()->get();
}
这样既保持了模型的表达力，又让 Repository 聚焦于业务组装。
是否需要为每个模型都创建 Repository？
不一定。对于简单的 CRUD 操作，尤其是后台管理类功能，直接使用 Eloquent 可能更高效。Repository 更适合那些有复杂数据处理逻辑或频繁变更数据源的场景。
判断标准：
- 该模型的操作是否跨多个表或服务？
- 未来是否会更换数据源（如 API、缓存、文件等）？
- 是否有大量重复的查询逻辑？
满足其一，就值得考虑使用 Repository。
总结
Repository 模式在 Laravel 中的价值在于解耦和抽象。关键在于合理使用，而不是盲目套用。重点包括：
- 用接口定义契约，便于依赖注入和测试
- 按业务语义封装方法，而非简单代理 Eloquent
- 结合本地作用域和 Criteria 处理复杂查询
- 只为真正需要的模型创建 Repository
基本上就这些，不复杂但容易忽略细节。坚持清晰的结构和明确的目的，才能发挥 Repository 的最大价值。
