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 中实现这套模式非常自然，利用其依赖注入和服务容器机制，可以轻松管理 对象 之间的关系。
基本上就这些。结构清晰了，后期加功能也不会慌。
