Service层处理业务逻辑，Repository层解耦数据访问。控制器仅负责请求响应，业务由Service实现，如用户注册包含创建用户、发邮件、设配置等；Repository提供统一数据接口，通过依赖注入实现解耦，便于测试与维护。分层核心是职责分明：Controller管HTTP交互，Service管流程，Repository管数据操作。
在Laravel项目中，随着业务逻辑的增长，控制器会变得臃肿，直接在控制器中处理数据操作和业务判断会让代码难以维护。为了解决这个问题，引入Service层和Repository层是一种被广泛认可的优雅做法。它们各自承担不同的职责，让代码结构更清晰、可测试性更强。
Service层：处理业务逻辑
Service层是业务逻辑的集中地。它不关心数据从哪里来，只关心“做什么”。比如用户注册、订单创建、积分发放等复杂流程，都应该放在Service中实现。
举个例子，用户注册不只是插入一条数据，还可能涉及发送欢迎邮件、生成默认配置、记录日志等。把这些逻辑写在控制器里显然不合适。
创建一个UserService：
class UserService
{
public function register(array $data)
{
// 开启事务
DB::transaction(function () use ($data) {
$user = User::create($data);
// 发送邮件
Mail::to($user->email)->send(new WelcomeEmail($user));
// 创建默认设置
UserSetting::create(['user_id' => $user->id]);
// 记录日志
activity()->on($user)->log('registered');
});
return $user;
}
}
然后在控制器中调用：
class AuthController extends Controller
{
public function register(Request $request, UserService $userService)
{
$user = $userService->register($request->all());
return response()->json($user, 201);
}
}
这样控制器只负责接收请求和返回响应，真正做事的是Service。
Repository层：解耦数据访问
Repository的作用是封装对数据库的操作，让Service不需要知道底层是Eloquent还是其他ORM，甚至可以切换数据源。它提供统一的数据接口，比如find()、all()、create()等。
定义一个UserRepository接口：
interface UserRepositoryInterface
{
public function findById($id);
public function findByEmail($email);
public function create(array $data);
}
再写一个基于Eloquent的实现：
class EloquentUserRepository implements UserRepositoryInterface
{
public function findById($id)
{
return User::find($id);
}
public function findByEmail($email)
{
return User::where('email', $email)->first();
}
public function create(array $data)
{
return User::create($data);
}
}
在Service中使用Repository：
class UserService
{
protected $userRepository;
public function __construct(UserRepositoryInterface $userRepository)
{
$this->userRepository = $userRepository;
}
public function register(array $data)
{
DB::transaction(function () use ($data) {
$user = $this->userRepository->create($data);
Mail::to($user->email)->send(new WelcomeEmail($user));
UserSetting::create(['user_id' => $user->id]);
});
return $user;
}
}
通过Laravel的服务容器绑定接口与实现：
// 在AppServiceProvider的register方法中
$this->app->bind(
UserRepositoryInterface::class,
EloquentUserRepository::class
);
以后如果想换成MongoDB或其他存储方式，只需新增一个Repository实现并修改绑定即可，Service层完全不用变。
何时使用Repository？
并不是每个项目都需要Repository。如果你确定长期使用Eloquent，且不打算更换ORM，那可以直接在Service中调用模型。但如果你追求更好的解耦、测试性和架构清晰度，Repository值得引入。
它的好处包括：
- 方便单元测试，可以用Mock替换真实数据库
- 业务逻辑不受ORM限制
- 多数据源支持更容易
- 团队协作时接口先行，前后端可并行开发
总结：分层不是越多越好，而是职责分明
使用Service + Repository的结构，并不是为了堆叠层次，而是为了让每部分专注自己的事情：
- Controller：处理HTTP相关逻辑（验证、响应格式）
- Service：处理核心业务流程
- Repository：处理数据存取细节
这种分工让代码更容易维护、测试和扩展。在Laravel中实现这套模式非常自然，利用其依赖注入和服务容器机制，可以轻松管理对象之间的关系。
基本上就这些。结构清晰了，后期加功能也不会慌。
