本文介绍如何将控制器中的产品创建逻辑提取到独立的仓储类中，通过接口绑定与依赖注入实现松耦合设计，提升代码可测试性、可维护性与可扩展性。
本文介绍如何将控制器中的产品创建逻辑提取到独立的仓储类中，通过接口绑定与依赖注入实现松耦合设计，提升代码可测试性、可维护性与可扩展性。
在 Laravel 应用开发中，将业务逻辑（如数据创建、查询、更新）硬编码在控制器中会导致职责混乱、难以单元测试、复用性差，且违反单一职责原则。理想的重构路径是引入仓储模式（Repository Pattern），将数据访问逻辑封装到独立类中，并通过接口契约与依赖注入实现解耦。
以下是以 Product 模型为例的完整实践步骤：
✅ 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
{
/**
* 创建新产品记录
* @param array $data 包含 name、en_name、type、cat_id 等字段的关联数组
* @return Product 新建的模型实例
*/
public function createProduct(array $data): Product;
}⚠️ 注意：接口中不包含具体实现，仅定义行为；命名需准确（如 ProductRepositoryInterface，而非示例中误写的 CategoryRepositoryInterface）。
✅ 3. 实现仓储类
app/Repositories/ProductRepository.php
<?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，可继承它以复用通用方法（如 find(), update()），但本例保持简洁，直接实现接口。
✅ 4. 在控制器中依赖注入并使用
修改控制器方法，移除硬编码逻辑，通过接口注入仓储：
use App\Repositories\ProductRepositoryInterface;
use Illuminate\Http\Request;
public function store(Request $request, ProductRepositoryInterface $productRepository)
{
// 数据预处理与验证建议前置（推荐使用 Form Request）
$validated = $request->validate([
'product_name' => 'required|string|max:255',
'product_name_english'=> 'nullable|string|max:255',
'product_type' => 'required|string',
'category_product' => 'required|integer|exists:categories,id',
]);
// 映射请求字段为仓储所需结构
$productData = [
'name' => $validated['product_name'],
'en_name' => $validated['product_name_english'],
'type' => $validated['product_type'],
'cat_id' => $validated['category_product'],
];
$newPro = $productRepository->createProduct($productData);
return response()->json(['message' => 'Product created', 'data' => $newPro], 201);
}✅ 5. 进阶建议（提升健壮性）
- 验证分离：将 $request->validate(...) 移至独立的 StoreProductRequest 类，实现验证逻辑复用；
- 事务支持：若创建涉及多表操作（如同时写入 products 和 product_logs），在仓储方法中包裹 DB::transaction()；
- DTO 封装：对复杂参数，可引入数据传输对象（DTO）替代关联数组，增强类型安全；
- Facade 替代方案？：Laravel Facade 适用于全局静态调用，但会破坏依赖显式性，不推荐用于仓储层；接口 + 依赖注入才是 Laravel 官方倡导的松耦合方式。
通过以上重构，控制器回归“协调者”角色——只负责接收请求、调用服务、返回响应；所有数据操作被隔离在仓储中，便于单独测试、Mock 模拟、横向扩展（如切换为 API 调用或缓存写入）。这是构建可维护 Laravel 应用的关键一步。
