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