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); } } </font> </p> <p>这样控制器只负责接收请求和返回响应，真正做事的是Service。</p> <H3>Repository层：解耦数据访问</H3> <p>Repository的作用是封装对数据库的操作，让Service不需要知道底层是Eloquent还是其他ORM，甚至可以切换数据源。它提供统一的数据接口，比如<code>find()</code>、<code>all()</code>、<code>create()</code>等。</p> <p>定义一个UserRepository接口：</p> <font face="Courier New"> <pre class="brush:php;toolbar:false;"> 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中实现这套模式非常自然，利用其依赖注入和服务容器机制，可以轻松管理对象之间的关系。
基本上就这些。结构清晰了，后期加功能也不会慌。