本文介绍如何将控制器中的产品创建逻辑抽离为独立的仓储类，并通过依赖注入和接口绑定实现松耦合设计，提升代码可测试性、可维护性与可扩展性。
本文介绍如何将控制器中的产品创建逻辑抽离为独立的仓储类，并通过依赖注入和接口绑定实现松耦合设计，提升代码可测试性、可维护性与可扩展性。
在 Laravel 应用开发中，将业务逻辑（如数据创建、更新、查询）从控制器中移出是践行“单一职责原则”与分层架构的关键一步。直接在 store() 方法中调用 Product::create() 虽然简洁，但会导致控制器承担过多职责，难以单元测试，也不利于未来切换数据源（如从 Eloquent 切至 API 或缓存层）。推荐采用仓储模式（Repository Pattern）+ 接口契约（Interface Contract） 实现解耦。
✅ 正确实践：定义接口 → 实现仓储 → 绑定服务 → 注入使用
1. 创建仓储接口与实现类
首先生成接口与具体实现类（建议统一置于 app/Repositories 目录）：
mkdir -p app/Repositories php artisan make:interface Repositories/ProductRepositoryInterface # 手动创建类（或使用 IDE 快捷生成），或运行： # touch app/Repositories/ProductRepositoryInterface.php
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;
}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 并非必需；若项目已抽象通用 CRUD 基类，可复用；否则保持轻量实现更清晰。
2. 注册服务容器绑定
创建服务提供者并注册接口绑定：
php artisan make:provider RepositoryServiceProvider
编辑 app/Providers/RepositoryServiceProvider.php：
<?php
namespace App\Providers;
use App\Repositories\ProductRepository;
use App\Repositories\ProductRepositoryInterface;
use Illuminate\Support\ServiceProvider;
class RepositoryServiceProvider extends ServiceProvider
{
public function register(): void
{
$this->app->bind(ProductRepositoryInterface::class, ProductRepository::class);
}
public function boot(): void
{
//
}
}然后在 config/app.php 的 providers 数组中注册该提供者：
App\Providers\RepositoryServiceProvider::class,
3. 在控制器中依赖注入并使用
修改控制器方法签名，Laravel 会自动解析并注入实现类：
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Repositories\ProductRepositoryInterface;
use Illuminate\Http\Request;
class ProductController extends Controller
{
public function store(Request $request, ProductRepositoryInterface $productRepo)
{
// 验证请求数据（务必保留！）
$validated = $request->validate([
'product_name' => 'required|string|max:255',
'product_name_english' => 'nullable|string|max:255',
'product_type' => 'required|string|max:100',
'category_product' => 'required|exists:categories,id',
]);
// 映射请求字段到仓储所需结构（关键适配层）
$productData = [
'name' => $validated['product_name'],
'en_name' => $validated['product_name_english'] ?? null,
'type' => $validated['product_type'],
'cat_id' => $validated['category_product'],
];
$newPro = $productRepo->createProduct($productData);
return response()->json(['message' => 'Product created', 'data' => $newPro], 201);
}
}⚠️ 注意事项与最佳实践
- 永远先验证再入库：控制器仍需负责请求验证与数据清洗，仓储只处理已校验的结构化数据。
- 字段映射由控制器完成：避免让仓储理解 $request 对象——它应只接收标准数组，提高复用性。
- 不要过度设计：若项目规模小、无多数据源需求，可暂用简单 Service 类替代完整仓储；但接口 + 实现的组合仍是面向未来演进的稳健选择。
- 配合类型提示与返回类型声明：如 : Product 可强化 IDE 支持与静态分析能力。
- Facade 不推荐用于此场景：Facade 更适合全局辅助函数（如 Cache::get()），而仓储需依赖注入以保障可测性与上下文隔离。
通过以上重构，你的 ProductController@store 不再关心“如何创建”，只专注“何时创建”与“创建什么”，真正实现关注点分离——这是构建可长期维护 Laravel 应用的基石。
