本文介绍如何将控制器中直接创建数据库记录的逻辑抽离为独立的仓储类，并通过接口依赖注入实现松耦合，提升代码可测试性与可维护性。
本文介绍如何将控制器中直接创建数据库记录的逻辑抽离为独立的仓储类，并通过接口依赖注入实现松耦合，提升代码可测试性与可维护性。
在 Laravel 应用开发中，控制器（Controller）应专注于处理 HTTP 请求与响应流程，而非承担数据持久化等业务逻辑。将 Product::create([...]) 这类操作硬编码在控制器中，不仅违反单一职责原则，还导致单元测试困难、复用性差、后期难以扩展（如需添加日志、事务、缓存或权限校验时）。理想的重构路径是引入仓储模式（Repository Pattern），配合依赖注入（DI） 与接口契约（Interface），实现逻辑分层与解耦。
✅ 正确的分层实践：仓储 + 接口 + 服务容器绑定
首先，明确核心组件职责：
- ProductRepositoryInterface：定义数据操作契约（如 createProduct(array $data): Product），不包含实现细节；
- ProductRepository：实现该接口，封装具体 Eloquent 操作，可复用模型实例、支持事务、预加载等；
- RepositoryServiceProvider：在服务容器中绑定接口与实现，使 Laravel 能自动解析依赖；
- 控制器：仅接收接口类型参数，完全 unaware 具体实现——便于 Mock 测试或未来切换为 API 客户端/缓存仓储。
1. 创建服务提供者并注册绑定
运行命令生成服务提供者：
php artisan make:provider RepositoryServiceProvider
在 app/Providers/RepositoryServiceProvider.php 的 register() 方法中完成接口绑定：
use App\Repositories\ProductRepository;
use App\Repositories\ProductRepositoryInterface;
public function register()
{
$this->app->bind(ProductRepositoryInterface::class, ProductRepository::class);
}别忘了在 config/app.php 的 providers 数组中注册该服务提供者：
App\Providers\RepositoryServiceProvider::class,
2. 定义仓储接口与实现
创建接口 app/Repositories/ProductRepositoryInterface.php：
<?php
namespace App\Repositories;
use App\Models\Product;
interface ProductRepositoryInterface
{
public function createProduct(array $data): Product;
}创建实现类 app/Repositories/ProductRepository.php（建议继承通用基类以复用 CRUD 逻辑）：
<?php
namespace App\Repositories;
use App\Models\Product;
class ProductRepository implements ProductRepositoryInterface
{
protected Product $product;
public function __construct(Product $product)
{
$this->product = $product;
}
public function createProduct(array $data): Product
{
// 可在此统一处理字段映射、默认值、验证前置逻辑等
return $this->product->create($data);
}
}? 提示：若项目已存在 BaseRepository，可让 ProductRepository 继承它，进一步抽象通用方法（如 find(), update(), delete()）。
3. 在控制器中依赖注入接口
修改控制器方法签名，直接声明接口类型参数，Laravel 会自动注入已绑定的实现：
use App\Http\Requests\StoreProductRequest;
use App\Repositories\ProductRepositoryInterface;
public function store(StoreProductRequest $request, ProductRepositoryInterface $productRepository)
{
$productData = $request->validated(); // 推荐使用 Form Request 验证
$newProduct = $productRepository->createProduct([
'name' => $productData['product_name'],
'en_name' => $productData['product_name_english'],
'type' => $productData['product_type'],
'cat_id' => $productData['category_product'],
]);
return response()->json(['message' => 'Product created', 'data' => $newProduct], 201);
}✅ 优势体现：
- 控制器不再 use App\Models\Product，彻底解除对 Eloquent 模型的强依赖；
- 单元测试时可轻松 Mock<ProductRepositoryInterface> 替换真实实现；
- 后续如需改为队列异步创建、调用外部 API 或增加审计日志，只需修改 ProductRepository，控制器零改动。
⚠️ 注意事项与最佳实践
- 避免过度设计：小型项目或 MVP 阶段可暂不引入仓储模式；但一旦业务逻辑增长（如需多源数据、复杂事务、策略切换），尽早分层收益显著。
- 请求验证分离：务必使用 FormRequest 或独立验证逻辑处理输入，仓储层只接收已清洗/可信数据。
- 不要在仓储中处理业务规则：如“库存不足不可创建”，这类规则应置于应用服务层（Application Service）或领域模型中，仓储专注数据存取。
- 接口命名清晰：接口名应体现能力（ProductRepositoryInterface），而非实现（避免 EloquentProductRepositoryInterface）。
- 保持接口精简：一个接口只暴露必要方法，遵循接口隔离原则（ISP）。
通过以上重构，你的控制器回归轻量、专注、可测的本质，而数据创建逻辑被封装在可独立演进、可复用、可测试的仓储组件中——这才是 Laravel 架构演进的专业路径。
